Exit, suppression, and completion rules
A checklist for ending GTM work cleanly, suppressing unsafe or obsolete runs, preventing duplicate work, and recording what completion means.
On this page
A workflow that starts reliably and never ends is a queue with a timer attached. Model the end states before adding more actions.
Four kinds of ending
| End state | Meaning | Example |
|---|---|---|
| Completed | The intended business result happened | Seller accepted the handoff |
| Suppressed | The work must not continue | Consent was withdrawn |
| Expired | The work waited past its SLA | No owner accepted the item |
| Failed | The system could not complete a step | External service returned an error |
These states should not collapse into one done field. A report needs to tell a successful workflow from a suppressed one and an operational failure.
Stable run keys
run_key = subject_id + ":" + decision_id + ":" + business_event_idStore the key, current state, started time, last attempt, and completion time. Before starting, search for an active run with the same key. If one exists, suppress the new run with reason duplicate-active-run. If a completed run exists, follow the re-entry policy from the workflow specification.
Suppression is an intentional outcome
Define suppression before the workflow is live:
- consent or do-not-contact state changes;
- the subject is merged, deleted, or no longer matches the population;
- the decision is superseded by a newer version;
- the owner or system of record is unavailable;
- a kill switch or volume limit is active; or
- a human has completed the work elsewhere.
When suppression happens, record the condition and who owns the next review. Do not delete the run history. It is evidence that the control worked.
Completion evidence
List one or two fields or events that prove the outcome. For a handoff, use accepted_at and an owner. For a customer message, use a provider event plus the permitted message ID. For an internal enrichment task, use the accepted value, source, and review status. The platform may provide a run log; retain the business evidence in the system that owns the record.
Decide which ending wins
A run can meet several ending conditions at once. Set precedence before launch. Safety suppression should normally beat a pending action; confirmed completion should beat a later timeout; a newer run should supersede an older open run. Without precedence, execution order becomes an accidental business rule.
Keep the workflow run separate from the subject's business status. A follow-up run may be completed while the opportunity remains open, or suppressed because the contact opted out while the account remains a customer. Combining those concepts in one field makes both automation and reporting unreliable.
Review terminal states
Report completed, suppressed, expired, cancelled, superseded, and failed work as distinct populations. Review the top reason codes and a sample of records in each. A high completion rate can hide work that was completed technically but produced no accepted business outcome. A growing suppression rate may show that the control works, or that upstream eligibility has become stale. The underlying records tell you which.
Related: Triggers, preconditions, and eligibility, Workflow states and job history, and SLA design and milestone dates.
Related guides
FAQ
- What is a workflow exit rule?
- An exit rule describes the observable event that proves the workflow has finished, such as an accepted handoff, a completed task, or an explicit disqualification. It is separate from a tool run succeeding.
- How do I prevent duplicate workflow work?
- Give each run a stable key made from the subject, decision version, and business event. Check for an active or completed run before creating another one, and record the reason when a duplicate is suppressed.
Get the next guide
New guides and the occasional note on GTM tooling. Don't worry, I won't drop you into a three-month nurture.