Loopy builds and updates your loops from what you write in Studio. Clear instructions lead to more reliable changes, especially as your loop handles more cases.
Writing the request
Describe the rule, not just the case that failed
When a run fails on one case, it’s natural to describe the fix in terms of that case. But Loopy has to generalize your example into a rule, and a rule inferred from a single example may key on the wrong signal.
Instead of
“For the Acme invoice, you should have looked in the Vendors folder. Please look there.”
Say
“Some invoices come from vendors instead of clients — you can tell because the record’s Type field says Vendor. For those, look in the Vendors folder instead of the Clients folder. The Acme invoice (record 00012345) is an example.”
The second version names two things the first leaves Loopy to guess: the population the rule applies to, and the deciding signal that identifies it. When you know a reliable field — a type, a status, a form number — say that’s the signal to use. A rule keyed to a guessable pattern, like a name format or a folder-name similarity, will eventually match cases you didn’t intend.
Two or three examples that span the variation beat one example every time.
Say what must stay the same
A change request naturally describes what should be different. It’s just as important to state what must not change: Tell Loopy what should stay the same, too. This helps prevent a targeted change from affecting behavior you already rely on.
Say
“Add the new filter to the search step. This must not change anything else — documents should still be filed and named exactly as they are today.”
This matters most when your loop handles several kinds of cases and you’re changing a step they all share, such as case selection, classification, or routing. Without the invariant, a rebuild that helps the new scenario can quietly shift behavior for the existing ones.
Use absolutes for facts, not for behaviors
Absolute statements are powerful when they express something that is always true in your business:
Say
“An invoice number always starts with INV-.”
“14G Forms are never a business return.”
Loopy turns facts like these into reliable, deterministic logic. State them confidently.
Be more careful with absolute behaviors — “always stop there,” “never send,” “only do X.” Loopy encodes them literally, and they hold until your business hits the case that contradicts them. If you’re not sure a behavior is final, say so:
Say
“For files marked DRAFT, create the record but pause before sending — I’m not certain yet what the full handling should be, so keep this easy to change.”
And when you revise a rule you set earlier, name it as a replacement:
Say
“This replaces the DRAFT-file behavior we set up last month.”
Otherwise the new rule can layer on top of the old one instead of superseding it.
One change per request, one topic per chat
Bundle related edits, but don’t stack unrelated ones. “Fix the folder matching and change the email template and add a new case type” gives you three ways for the build to surprise you and no clean way to tell which change caused what. Focused requests make each change easier to review and test.
The same rule applies to the conversation itself: keep one class of change per chat. When you start an edit from the loop page, you’re asked whether to continue an existing chat or start a new one.
Continue the existing chat when the edit is tied to a previous one — refining the rule you just changed, or fixing something that change surfaced. The earlier context still applies, and you want Loopy to have it.
Start a new chat when the edit is unrelated to anything in that conversation. Otherwise the earlier instructions stay in scope, and the new rule can layer onto them instead of standing on its own.
Before you approve
Ask what else the change affects
Before approving a build — especially one that touches how cases are selected, classified, or routed — ask:
Ask
“Before you build: which of my existing case types does this change affect, and what’s the risk to each?”
Loopy can help identify which existing cases may be affected, giving you a useful checkpoint before you approve the build. A change to a single downstream step usually affects only that step; a change to a shared decision point affects every case that flows through it. This question tells you which kind you’re approving.
After the build
Test the change, and the things that weren’t supposed to change
The natural test is the case that prompted the change. Run that — but if the change touched shared logic, re-run one example of each kind of case your loop handles. Keep a short standing list:
For example
My loop handles standard cases, rush cases, vendor cases, and cases with missing contact info. After any change to selection or routing, I test one of each before going live.
You can put it in the request itself: “After the build, I’ll verify with case A (standard) and case B (vendor) before promoting.” A few minutes of checklist testing catches the regressions that otherwise surface in production a week later.
Promote only once the checklist passes
Every build publishes as a test version first. Iterate there and promote to live only after your checklist passes.
A completed run isn’t always a correct run. Open the output — the document, the draft, the record — and look at it before you promote. A run can finish cleanly while producing output that isn’t what you wanted.
When something goes wrong
Check your inputs first
When a run finds zero matching cases, or skips something you expected, check the loop’s input values before assuming the logic broke. A typo in a name, an out-of-date date range, or a stale filter value produces exactly the same symptom as a broken query — and takes one edit to fix.
Report problems so they can be solved in one round trip
The fastest diagnoses come from reports that include:
The run ID (shown on every run) and the specific case or record number
What you expected versus what happened — “the file should be in folder X; it’s in folder Y”
A direct link or screenshot of the evidence: the file in its actual location, the record, the output
Instead of
“This still isn’t working.”
Say
“Run 0198xxxx, case 00012345: the signed document should have been filed in Clients > Acme > 2026, but I found it in the top-level Acme folder. Link: …”
Frustration is understandable when something regresses, but the concrete version of the report is what turns a multi-turn back-and-forth into a one-reply diagnosis.
Still stuck? Contact Caddi support with the run ID, the exact error message you’re seeing, and the time it occurred.
Know when to bring in the Caddi team
If you’ve tried to make the same change a few times and still aren’t getting the behavior you expect, loop in your account manager or the Caddi team. Share the relevant run IDs, what you expected to happen, and what you’ve already tried so we can help diagnose the issue quickly.