Rerun and Run From Here
You found the bug and fixed it. Re-firing the whole trigger to check costs another AI call, another API request and a CRM record you cannot get back — so do not.
Debugging is a loop: run, read, fix, run again. The second run is where it gets expensive. Everything upstream of your fix runs a second time — the model call, the paid API request, the search — and some of it cannot be repeated honestly, because the record has moved on since.
There are three ways to run something again, and picking the right one is most of what makes debugging fast.
The three re-runs
| What you do | What executes | Reach for it when |
|---|---|---|
| Run | ||
| Run From Here | ||
| Fire the trigger |
Run
- What executes
- Reach for it when
Run From Here
- What executes
- Reach for it when
Fire the trigger
- What executes
- Reach for it when
Run From Here is the one to internalise. It keeps the expensive part of the run — the model output, the API response, the CRM snapshot — and re-executes only from your fix downward. A loop that took two minutes and cost real money becomes a loop that takes two seconds and costs nothing, which changes how willing you are to test properly.
The loop, in practice
- Read the run and find the first node whose output is wrong. Not the first node that looks wrong on the canvas — the first whose output does not match what you expected.
- Open it, and read the runtime input it received. If the input is already wrong, the defect is above and you are in the wrong node.
- Fix the configuration and press Run to see that node alone produce the right output.
- Then press Run From Here to confirm everything downstream is happy with the corrected value.
- Only when that is clean, fire the trigger once for real.
The bug this always turns out to be
A worked example that is worth more than the buttons. A CRM Manager node was configured with its entity type typed as contactss — one extra letter. The node completed. A task was created. Nothing failed.
But the task's entity_type and entity_id both came back empty, because the record it was supposed to be attached to could not be resolved. The creation succeeded; the linkage silently did not. On the canvas that is a green node. In the CRM it is a task floating unattached to anything, discovered weeks later by somebody wondering why a contact has no history.
Correcting the field and pressing Run From Here produced a real entity type and a real id in the same node's output — the fix confirmed in seconds, without another trigger, another model call or another record.
That is the shape to remember. A typo in a value did not produce an error. It produced an output with empty fields in it. Reading the output rather than the status is the single habit that makes this course's warnings actionable, and Run From Here is what makes reading it cheap enough to do every time.
What breaks
Run From Here reuses the old upstream data, which is the point and the trap. If the defect was actually upstream — a search returning the wrong records, a trigger reading the wrong field — re-running from below will keep handing you the same bad input and every fix will look like it failed. If two attempts at a fix change nothing, stop fixing and go up a node.
Re-running a node repeats its side effects. A node that sends an email sends another one. A node that creates a record creates a second. Neither button is a dry run, and there is no undo — so when the node you are debugging writes to something, expect to clean up after yourself, and prefer a test recipient and a throwaway record.
A fix that is not saved is not being tested. Run and Run From Here sit beside Save for a reason. Editing a field and immediately running can test the old value; press Save first, every time, until it is reflex.
Downstream nodes may hold state from the previous run. Re-running a section that writes to a record and then reads it back can see the earlier attempt's data. When a result looks impossibly correct, or impossibly stale, fire the trigger cleanly once before you believe it.
Try it
- Break one field in a middle node — a misspelled entity type is the classic — and fire the trigger. Note that the node completes.
- Read that node's output and find the empty fields. That is the whole diagnosis.
- Fix the field, Save, and press Run. Confirm the output is now populated.
- Press Run From Here and watch the downstream nodes re-execute with the corrected value while nothing upstream runs again.
- Finally break something in the trigger instead, and try to fix it with Run From Here. It will not work — and knowing why is worth the two minutes.
Next: AI-led debugging — handing a failed node to a model that can read the whole run, and knowing what to do with what it says.
Related lessons
Base rates — what a piece of evidence is actually worth
A face-recognition system that is 99.9% accurate and almost entirely wrong, and a number that sent an innocent woman to prison. Both are the same arithmetic, and it is the arithmetic that decides what any piece of evidence is worth.
ReadConfirmation and survivorship — what you never looked for
Two questions about evidence you did not go looking for. One is a rule you have to discover, and one is a pattern in five famous people — and in both, the thing that would have told you the truth is the thing nobody checks.
ReadLoss aversion, sunk cost and regression — what it costs you
Four questions you answer about yourself rather than about a scenario, and your own answers are the finding. Then the pattern that makes praise look useless and criticism look like it works, whatever you actually do.
Read