# 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.

- **Status:** Available
- **Audience:** both
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/compare/scheduled-vs-triggered/

## 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.

> **Note** That 24-hour bound is worth internalising when you set a due time. A commitment with a precise time is a promise about a moment; one with a vague time is a promise about a day. The system can keep either, and the customer will judge you against the one you made.

## 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

1. 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.
2. Prefer the vaguest due time that is still honest.
   - Result: An unnecessary precision turns an ordinary delay into a broken promise.
3. 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.
4. 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](/docs/troubleshooting/follow-up-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.

## Related

- [Due dates and times](https://connectbyjbrh.com/docs/follow-ups/due-time/)
- [Overdue follow-ups](https://connectbyjbrh.com/docs/follow-ups/overdue/)
- [Executing a follow-up](https://connectbyjbrh.com/docs/follow-ups/execution/)
- [A follow-up did not go out](https://connectbyjbrh.com/docs/troubleshooting/follow-up-not-executed/)
- [Executing a follow-up, end to end](https://connectbyjbrh.com/docs/workflows/execute-follow-up/)
- [Why only one loop may think](https://connectbyjbrh.com/research/single-thinker/)

## What this page is based on

- Connect capability registry (docs-source/facts.py) — `followups`, `phone_followup_drain`
- docs-source/facts.py — MEASURED.phone_followup_max_late_hours
- docs-source/sources/GENERAL.md §7 — follow-ups