Automation rule
A written statement of three parts: when this happens, if these things are true, then do that. A rule is the place a process stops living in somebody's head and becomes something a colleague can read, argue with, and change.
Why it matters in practice. The value of the rule set is that it is reviewable — which means it is also a liability if it is never reviewed. Rules accumulate faster than the processes behind them are retired, so a workspace ends up automating a habit that no longer exists. A rule nobody can explain out loud is a rule nobody can repair.
Often confused with Trigger, Action, Exception.
Trigger
The moment that starts a rule: a stage moved, a status changed, an invoice state flipped, a due date passed. It is a fact that already happened, not something a person was supposed to remember.
Why it matters in practice. A trigger attached to a real state change is one you can defend; a trigger attached to a routine someone performs is usually a record that was never created. The dangerous trigger is the unscoped one — a status change meant for one kind of case starts firing across every record of that type, and a rule that fires wrongly is worse than no rule, because people stop trusting the correct ones too.
Often confused with Automation rule, Scheduled job, Notification.
Action
The thing the rule does once the trigger and the conditions match: create a task, assign it, change a status, send a message, raise a request for approval. A rule can take several actions, and each one is a real change to a real record.
Why it matters in practice. Actions are the part that writes data, so this is where automation earns or loses its place. An action that touches money or a commitment belongs behind an approval step rather than running unattended, and any action that creates a record must be safe to run twice — otherwise the second run is a duplicate, not a no-op.
Often confused with Automation rule, Approval workflow, Idempotency.
Approval workflow
A step in a process where the work stops and waits for a named person to decide, and continues only if that person approves. It lets a rule carry the routine volume while the judgement stays with whoever is entitled to make it.
Why it matters in practice. The point is not to slow things down but to move the decision to the right desk. A rejected request should leave the underlying record untouched, so the approval is a gate rather than a second version of the work. It is a different concern from a value limit: the approval answers who decides, not how much.
Often confused with Escalation, Exception, Threshold approval.
Escalation
Routing a piece of work to a different or higher recipient because a condition was met — a deadline passed, a request sat unanswered, a value exceeded what the first person may approve. It changes who is holding the item, not just how loudly it is announced.
Why it matters in practice. An escalation with no named recipient is not escalation, it is a second notification and a queue nobody owns. The honest test is whether anybody can say who receives it and what they are expected to do, because an escalation nobody receives has quietly become a write-off.
Often confused with Approval workflow, Notification, Override.
Exception
A case the rule deliberately does not handle, or one it passes to a person. It is an explicit part of the design rather than an oversight: the rule covers the ordinary path and names where judgement is required.
Why it matters in practice. Exceptions are what keep a rule small enough to read. The failure mode is the opposite — encoding every possible oddity into the condition until nobody can follow it, and the exceptions then surface as annoyed messages instead of as a list somebody reviews. Give the exception list an owner and a review date, or it becomes the rule nobody trusts.
Often confused with Automation rule, Approval workflow, Audit trail.
Batch job
A single run that processes many records together rather than one record at a time — recalculating a field across a segment, updating every record of a type, sending a run of dated reminders. It is a unit of work with a start and an end, not a continuous background presence.
Why it matters in practice. Partial failure is the thing to plan for: a batch can complete for most records and fail on a handful, and the failure is invisible unless the run itself is inspected. A batch that is not safe to re-run turns a transient error into a monthly manual repair, and the repair is always done by whoever is nearest, which is not a good reason to choose one.
Often confused with Scheduled job, Retry, Idempotency.
Idempotency
The property that performing the same operation again leaves the system in the state it was already in — running it twice is the same as running it once. An idempotent action can be repeated safely; a non-idempotent one creates a second record, a second charge, or a second message.
Why it matters in practice. This is the property that makes every retry decision safe, and its absence is what turns a network hiccup into a correction task. If an action can create a document or move money, ask what happens when it runs twice before trusting it, and prefer an action that recognises work it has already done over one that blindly creates.
Often confused with Retry, Batch job, Invoice numbering.
Retry
Attempting a failed operation again, usually after a delay and up to a stated number of times. It exists because most failures are temporary — a connection dropped, a service was briefly unavailable — and a first failure is not evidence that the work should be abandoned.
Why it matters in practice. A retry is only safe where the underlying action is idempotent. A retry that is not idempotent double-posts, which is a worse outcome than the failure that caused it. Retries also need a cap: unbounded retrying turns one flaky step into a flood of duplicate work, and a capped retry needs somewhere for the exhausted case to land rather than disappearing.
Often confused with Idempotency, Batch job, Exception.
Scheduled job
Work that runs at a chosen time or on a chosen interval rather than in response to a record changing. A nightly recalculation, a weekly summary, a monthly ageing refresh — the trigger is the clock, not an event.
Why it matters in practice. Time-based work has no event to inspect, so a run that has quietly stopped for a month is genuinely invisible. Scheduled work also reads whatever state the data happens to be in at that hour, so a record entered late can be processed against a stale value — a data-quality obligation disguised as a configuration one.
Often confused with Trigger, Batch job, Day-end close.
Notification
A message sent to a person that something happened: a rule fired, a request is waiting, a date has passed. It is a communication, not a record, and it is usually the most visible and least durable part of a process.
Why it matters in practice. Volume is the failure mode. When the count of messages rises, people start ignoring them, and the automation that depended on someone reading is now depending on attention that no longer exists. A notification that arrives with nothing attached — no record, no next action, no way to say it was handled — is noise, and the useful version links to the work it is about.
Often confused with Escalation, Trigger, Hand-off.