The execution log: run one, then read it
Your org's run history is empty, and that is correct. Create one enquiry, then read everything your org did about it in the next fifteen seconds.
Everything so far has been reading. This is the other half of the loop, and it is the half that separates people who can support an Expedify client from people who can describe one.
Why your log is empty
Your demo org arrived with its workflows and none of their history. That is deliberate: a clone carries the business — the enquiries, the contacts, the automations, the knowledge — and not the record of what somebody else's copy did last Tuesday. So every Executions tab in your org is blank until you make it run — which, now that you have switched three workflows on, takes one record.
Fire it for real
Not a shortcut, not a test button — the thing production does. These workflows start when an enquiry is created, so create one.
- Check the three from the last lesson are still active. If you skipped that step, nothing below will happen and the empty log will be your own doing.
- Open the deals board and add an enquiry. Give it a name, a value of
3500000— thirty-five lakh, an ordinary ticket for this business — and leave the source blank on purpose. - Wait fifteen seconds. Several things are happening that you did not ask for.
- Open
2.3 · Mark every lead hot, warm or cold — and say whyand go to its Executions tab. There is a run in it now, and it is yours.
One enquiry started the 3 workflows you switched on in the last lesson. Nothing chained them together; they are three independent automations that happen to be watching the same event, and they ran within a second of each other:
| Workflow | What it was waiting for |
|---|---|
2.3 · Mark every lead hot, warm or cold — and say why | A new record on the deals table. Same trigger, same moment, different job. |
3.1 · Call every new lead back within 5 minutes | A new record on the deals table. Same trigger, same moment, different job. |
7.1 · Give the lead to the right person, and tell them | A new record on the deals table. Same trigger, same moment, different job. |
2.3 · Mark every lead hot, warm or cold — and say why
- What it was waiting for
- A new record on the deals table. Same trigger, same moment, different job.
3.1 · Call every new lead back within 5 minutes
- What it was waiting for
- A new record on the deals table. Same trigger, same moment, different job.
7.1 · Give the lead to the right person, and tell them
- What it was waiting for
- A new record on the deals table. Same trigger, same moment, different job.
This is the single most useful thing to show a client, and it is also the one to be careful with. Work happening without anyone asking for it is the product's whole promise — and it is why a change to one workflow can surprise you somewhere else entirely. When something unexpected happens to a record, ask which workflows watch it, not which one you were looking at.
What a run record holds
| In the record | What it tells you |
|---|---|
| Status and duration | Did it finish, and how long did it take. Duration is the column people ignore and then need — a workflow that has quietly gone from a second to fifteen is telling you something before anyone reports a fault. |
| One entry per node that ran | In order, each with its own success flag. This is where you find which node went wrong. |
| The path each node took | For a decision box, which arm. This one field answers most questions on its own. |
| Every node's output | What it actually produced — not what it was configured to produce. This is where you find why. |
Status and duration
- What it tells you
- Did it finish, and how long did it take. Duration is the column people ignore and then need — a workflow that has quietly gone from a second to fifteen is telling you something before anyone reports a fault.
One entry per node that ran
- What it tells you
- In order, each with its own success flag. This is where you find which node went wrong.
The path each node took
- What it tells you
- For a decision box, which arm. This one field answers most questions on its own.
Every node's output
- What it tells you
- What it actually produced — not what it was configured to produce. This is where you find why.
Read it in that order every time: the list tells you where, the node tells you why. Going straight to a node is how people spend twenty minutes debugging one that ran perfectly.
Read your own agent's prompt
Open the agent's entry in the run you just made. It kept two versions of its prompt: the one that is saved on the node, with the curly brackets still in it, and the one the model was actually handed, with real values in their place.
Find the line you added in the last lesson but one. It is in the second version with a real deal number in it. That pair — written and resolved, side by side, on every run — is how you answer “why did the AI say that?” without guessing, and it is the answer to the question that decides deals.
Which arm did it take?
Now open 3.1 · Call every new lead back within 5 minutes and read its run.
- The decision box recorded the two numbers it compared and the answer. Your enquiry was thirty-five lakh against the crore you set last lesson, so the answer is No.
- Count the nodes in the record. The high-priority task is not among them — that arm was not taken, so it did not run, and nothing in the record apologises for it. The note is there, because both arms run on into it.
- Put the threshold back to
2875000, and take theDeal numberline out of the agent's prompt if you would rather leave the org as you found it.
Green is not the same as right. Every failure this module has warned about produces a completed run: the reference that printed itself, the sentence with a hole in it, the arm that quietly did nothing. Filtering this list to failures will show you an empty list on a workflow that has been wrong for a month. Read the successful ones.
Try it
- Create a second enquiry, this time above a crore, and compare the two runs of the same workflow side by side.
- Find a node in one of your runs whose output surprised you, and work out from the record alone which earlier node caused it.
- Delete nothing. Your execution log is now the only history this org has, and the rest of the course reads it.
Module 2 is done. You can open any of the 19 workflows in your org, say what starts it, read what each box is configured to do, follow a value from one box to the next, see where it forks, and check what it really did. Module 3 walks the whole catalogue in the order a customer meets it.
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