Scheduled work and triggered work
Triggered work begins because something arrived — a message, a call, a webhook — and its job is to respond. Scheduled work begins because a time came round, and its job is to keep a promise made earlier. The difference that matters is age: a trigger acts on something current, while a scheduled action was decided in the past and has to be re-checked against the present before it runs.
The two clocks#
| Triggered | Scheduled | |
|---|---|---|
| What starts it | An external event arriving | A due time being reached |
| How old the decision is | Seconds | Hours or days — it was made when the commitment was created |
| What it is trying to do | Respond to what just happened | Keep something that was promised |
| What makes it wrong | Missing it, or answering twice | Running when it is no longer appropriate |
| Where lateness shows | As a slow reply | As an action arriving after it stopped being useful |
| Retry behaviour | Providers retry, so the same event can arrive more than once | The due item stays due until it is done, skipped or expires |
The most common misunderstanding is that these are two speeds of the same thing. They are two kinds of decision. A trigger has all the context it needs, because the thing that caused it is right there. A scheduled action carries only what was known when it was created, which is why it has to look around before acting.
Where they collide#
The interesting cases are the ones where both clocks point at the same customer. Somebody promises to call on Tuesday; on Monday the customer emails and the matter is settled. The scheduled call is now a promise that would be strange to keep.
- A due follow-up is checked against what happened since. A commitment created three days ago is not executed blindly because a date arrived.
- A reply can create a commitment, so triggered work regularly produces scheduled work — that is the normal direction of travel.
- Duplicates are a real failure mode. Two commitments about the same thing produce two contacts, which reads worse to a customer than none.
- Lateness is bounded on the phone. A phone follow-up that is more than 24 hours late is not simply executed as though nothing had happened; a call that arrives a day after it was promised is its own kind of mistake.
Why lateness is not the same as failure#
- A trigger that is late
- Still worth completing. A reply an hour after the message is a slower reply, not a wrong one.
- A scheduled action that is late
- Sometimes worth completing, sometimes not. Its value was tied to a moment, and the moment may have passed.
- A scheduled action that is stale
- The world moved under it: the deal closed, the case was resolved, the customer already got their answer. Running it is the failure.
- A duplicated action
- Two of anything is worse than one late one. This is the failure mode worth designing against rather than tolerating.
Which is why the useful question about a queue of due work is not *how many are overdue* but *how many are still worth doing*. A list of forty due items where thirty are stale is a different problem from forty that all still matter, and the same number describes both.
Using the two deliberately#
Give a commitment a reason as well as a date.
Result The reason is what lets the action be judged later — a follow-up whose purpose is already served can be recognised as such.
Prefer the vaguest due time that is still honest.
Result An unnecessary precision turns an ordinary delay into a broken promise.
When a customer resolves something early, close the commitment rather than leaving it to expire.
Result You avoid the second contact, and the record says the matter ended rather than that a promise lapsed.
Treat a repeated overdue item as a signal about the rule, not the item.
Result Something is producing commitments the business does not intend to keep, and fixing the source is cheaper than clearing the queue every week.
If a due item did not run at all, a follow-up was not executed separates the causes; if it ran at an odd hour, the due time itself is usually the explanation.
Questions#
Does scheduled work happen even when nobody is signed in?
Yes — that is the point of it. Scheduled work runs against the workspace rather than against your session, which is why a commitment made on Friday can be kept on Monday morning without anybody opening the application. What still applies is the autonomy rule for the channel it would use.
Can the same event be handled twice?
Providers retry, so an event genuinely can arrive more than once, and handling has to be written so that a repeat does not produce a second reply. That is a different problem from a duplicated commitment, which comes from two decisions rather than from one event arriving twice.
Why did a follow-up not run at exactly its due time?
Due work is drained rather than fired at an instant, so a small delay is normal and is not a fault. What is not normal is a large one, and on the phone there is a limit past which a late call is treated as no longer appropriate rather than simply made anyway.