A loop’s inputs are its configurable values — the initials that go on a form, the template to use, the folder documents are filed in. They sit alongside the loop’s logic rather than inside it, which is the point: a value that varies between people, or changes over time, can be updated without rebuilding or editing the loop.
You set an input once and Caddi reuses it for every run until you change it. This article covers where to set inputs, the difference between Personal and Team inputs, how to decide which an input should be, and what to do when inputs change after a loop update.
Setting your inputs
Open the loop, find Inputs in the right sidebar, and select Edit. The panel lists every value the loop asks for, grouped into Personal Inputs and Team Inputs. There are two ways to fill them in.
Set in a chat — describe the run you want in plain English and Loopy sets the inputs for you. Use this when you know the outcome you want but not which field controls it. Chat sets your personal inputs only; it never changes a team input.
Set manually — type into the fields yourself. Faster when you already know exactly which value is changing.
A field you’ve changed is marked Modified and the button at the bottom of the panel changes from Done to Save changes. There is no separate loop-level default sitting behind your value — what you save is what the loop uses, and Modified simply means you’ve edited the field since it was last saved.
Nothing is saved until you select Save changes. Closing the panel with the X discards whatever you’ve typed.
Every input must have a value before the loop can run. If any input is unset, the run fails validation and stops before it starts, rather than running with a blank.
Personal inputs vs. Team inputs
Every input is one or the other.
Personal Inputs — unique to you. Each person who runs the loop sets and keeps their own value, so changing yours changes nothing for anyone else.
Team Inputs — shared by everyone who runs the loop. One value, used by every run, no matter who starts it. The owner sets these centrally; everyone else sees them locked and cannot change them.
The owner decides which one an input is, using the toggle on each field: Personal (“each user sets their own”) or Shared (“all users see the same value”). Any kind of input can be either, including list and mapping inputs.
The same input can be either. Runner Initials is a personal input on one loop and a shared team input on another. Nothing about the field itself decides that — the owner does, based on how the loop is meant to be used.
Which one should an input be?
If changing the value would change how the workflow is supposed to operate for everyone, it should usually be a team input. If the value represents the individual running the workflow, or their personal preference, it should usually be personal.
A second test that reaches the same place: if you’d have to send an email telling everyone to update it, it should be shared. A team input is maintained in one place — the owner edits it once and every run picks up the change. A personal input is maintained by each person separately, which is how the teammate who joined last month ends up still running last quarter’s template name.
Likely team inputs
Form or template name
Task type or subtype
Task-status criteria, when everyone should use the same selection logic
Repository or folder destination, when documents always go to the same location
Mapping tables and naming conventions — anything that encodes firm policy
Other constants that define the intended workflow
Likely personal inputs
Initials
Signature information
User-specific email information
User-specific output destinations, statuses, or tags — where the workflow is intentionally different per person
Other values that are meant to differ for each person
A worked example. On a document-generation loop, Form Template Name, Task Subtype and Task Status are all team inputs — they define what the loop is supposed to produce and which records it acts on, and they should not vary by who happens to run it. Runner Initials stays personal, because it identifies the person running it.
Team inputs are guardrails
A team input is more than a convenience. It records what your organization expects to be true every time the loop runs — the template that should be used, the status that counts as done, the place documents belong.
So treat a proposed change to a team input as a change to the workflow, not a change of preference. When someone believes a team input needs to change, that is a signal worth following: understand why, and confirm the change is intended for everyone before making it.
This matters most for the values that define what the loop does — the template, the subtype, the status criteria. Changing one of those can materially change how the loop operates for every person who runs it, so it deserves the same review you’d give an edit to the loop itself. The questions in Loop Studio Best Practices apply here too: what else does this affect, and which cases does it change?
Changes are recorded, but not announced
The loop’s Timeline shows which input was changed and who changed it. The value itself isn’t displayed there, so a Timeline entry tells you that a guardrail moved and who moved it, without exposing the contents to everyone reading the history.
Nobody is notified when a team input changes, though. If you own a loop other people rely on, tell them when you change a team value — especially one that changes what the loop produces. A teammate whose output suddenly looks different has no prompt to go and check.
Saved values, one-off runs, and schedules
Saved values are the default for every run, but a manual run doesn’t have to use them.
A one-off run. When you start a run or a test manually, you can change input values for that run without saving them. Adjust the values, run, and your saved values stay as they were. This is the way to try something once without disturbing what the loop normally does.
Saving a change. If the new value is one you want to keep, select Save changes. Setting inputs through chat always saves — chat has no one-off mode.
Scheduled runs. A scheduled run uses the saved values: the team inputs, plus the personal inputs of whoever set up the schedule. Nobody adjusts anything at run time, which is the point — a scheduled loop should be something you can trust without inspecting it beforehand.
That last point is worth sitting with. If a loop runs on a schedule and has a personal input like Runner Initials, every scheduled run uses the scheduler’s value — not the value of whoever looks at the output later. If that isn’t what you want, the input probably belongs in Team inputs.
It also means a stale team input on a scheduled loop is easy to miss. The loop keeps running successfully, just with an out-of-date value.
What happens when a loop is shared
Sharing a loop passes on the team values, not the personal ones.
Team inputs arrive already set. The person you shared with sees the values and cannot change them. If one needs to change, they ask you — and that conversation is the review described above, not a hurdle.
Personal inputs start out unset. Each new person fills in their own. Your values are yours; they are not copied to anyone else.
Because a loop won’t run until every input has a value, someone who hasn’t set their personal inputs gets a validation failure rather than a run under the wrong values. That is the safe failure, but it is still a stumble on someone’s first attempt.
If you’re sharing a loop: tell people that they need to set their personal inputs before their first run, and what each one is for. And check that anything which defines the workflow is a team input rather than a personal one — that is what stops it drifting once several people are running the loop.
If a loop was just shared with you: open Inputs → Edit and fill in the Personal section before your first run. The team values are already set and are not yours to change.
Who can change what
The loop owner — sets the team values, and decides whether each input is personal or shared.
Everyone else with access — sets their own personal inputs. Team inputs are visible but locked.
This sits alongside the loop’s permission levels rather than replacing them. Viewer, Can run, and Editor control access to the loop itself; changing team inputs and flipping an input between personal and shared stay with the owner, even for an Editor. See Organization Teams for how sharing and permission levels work.
Because only the owner can change team inputs, ownership needs to keep up with your team. Transfer a loop’s ownership before removing someone from your organization — a suspended owner leaves the loop locked until they are reinstated or removed. When ownership transfers, control of the team inputs transfers with it.
Input values are visible to everyone the loop is shared with, including people with view-only access. Inputs are configuration, not a private note — don’t put anything in one you wouldn’t want everyone on the loop to read.
When inputs change after a loop update
Most of the time, editing a loop leaves your saved values alone: they survive a rebuild and a promote-to-live. Two things clear them.
An input’s type changes. If a rebuild turns a single value into a list, for example, the old value can no longer fit and is cleared.
An input is renamed or removed. The old value is dropped rather than carried across.
Either way you get a clear stop rather than a silent wrong answer: the loop will not run until every input has a value, so an emptied input fails validation instead of running blank.
When an input comes back empty, find out what changed before you refill it. An input whose type changed is a sign the step using it now works differently, and the value it needs may not be the value it had. Ask Loopy in Studio what the new version does differently, then set the input to match. Putting the old value straight back can produce a run that completes cleanly and does the wrong thing.
Two things loop owners should know
Test and live versions hold their own values. They can differ in which inputs exist and what type each one is, so you can test with different values without touching what the live loop uses. When you promote a test version, its input values go live with it.
Setting inputs during a build only sets them for you. Studio helps whoever is building fill in the inputs before testing, but that does not set personal inputs for anyone else the loop is shared with. After a change that adds or retypes an input, tell your team to open the panel — their first run will otherwise fail validation.
When to check your inputs
Before your first run of any loop that was shared with you — your personal inputs start empty.
After the loop changes, per the section above.
When a run finds nothing, or the wrong thing. A typo in a name, a stale date range, or an old template name produces exactly the same symptom as broken logic and takes one edit to fix. Rule out your inputs before reporting a bug — see Loop Studio Best Practices.
When you take over a loop, since the team values are now yours to maintain.
Common questions
Can I run the loop once with different values?
Yes. Start the run or test manually, change the values in the panel, and run without saving. Your saved values are untouched. Setting values through chat always saves them, so use the manual route for a one-off.
I can see a team input but can’t edit it. Why?
Only the loop’s owner can change team inputs. That is deliberate — a team input is the organization’s setting, not an individual’s. Ask the owner, and expect a short conversation about whether the change is right for everyone.
Can an input be shared for some people and personal for others?
No. Each input is one or the other for the whole loop.
My loop suddenly won’t run and says an input is missing.
A loop update most likely renamed an input or changed its type, which clears the saved value. Open Inputs → Edit, and check what the new version does before refilling.
My teammate ran the same loop on the same record and got different output.
Compare your personal inputs first — that’s the usual cause, since each of you sets your own. If the value is one that should never differ between people, it belongs in Team inputs; ask the owner.
Should I put an API key or password in an input?
Never. Inputs are for configuration values, not credentials, and they are visible to everyone the loop is shared with. Connect the tool through Integrations so Caddi manages the credential properly.
Can I see who changed a team input?
Yes — the loop’s Timeline records which input changed and who changed it. The value isn’t shown in the Timeline entry.
The short version
Inputs are configurable values that sit outside the loop’s logic, so they can change without rebuilding the loop.
Team inputs are for values that should be the same no matter who runs the loop. Personal inputs are for values that are meant to differ by person.
The rule: if changing it changes how the workflow operates for everyone, it’s a team input.
A team input is a guardrail — treat a request to change one as a workflow change, and tell people when you change one, because nobody is notified.
Nothing saves until you select Save changes, and closing with the X discards your edits.
A manual run can use different values just for that run; scheduled runs use the saved values and the scheduler’s personal ones.
Sharing a loop passes on the team values only — each new person sets their own personal inputs before their first run.
A loop won’t run with an input unset, so an emptied input fails validation rather than running blank. Find out what changed before you refill it.
Still stuck? Contact Caddi support with the loop name and the input values you were using when the run went wrong.