Terminal State Configuration
Direct answer. Terminal state configuration is the setting that governs what a record becomes when an automated sequence stops trying. A dunning sequence exhausts its retries; a follow-up cadence sends its last message; a reminder cycle reaches its final attempt. In each case the system writes a status, and that status is the only thing downstream systems can see. Because the setting is chosen during installation and is not surfaced in day-to-day reporting, the state these records end in can be unknown to the person who owns the outcome.
A bounded sequence has a last attempt
Dunning retries run out. Follow-up cadences send a final message. Reminder cycles reach a last attempt. Escalation chains reach the top. In each case the system writes a status, and that status is the only thing any downstream system can see.
Terminal state configuration is the part of the design that decides what that status is: which value is written, whether the record stays active, whether an event is emitted, and which other systems are told. It is distinct from the sequence itself — the schedule and the messages — which is the part that receives attention during setup.
Identical sequences, different operational positions
Two businesses can run the same cadence and end in completely different places. One leaves a closed record with no owner: the population is unqueryable, so no queue exists and no report can count it. The other leaves an open, queryable state that a person or an automation is explicitly assigned to. The sequences are identical; the terminal state is not.
This is why the setting is worth reading directly. It usually sits in an installation or configuration screen rather than a dashboard, it was chosen once, and the person who owns the outcome is often not the person who chose it.
What to check
- For each bounded sequence, find the configured behaviour after the final attempt.
- Record the exact status value written to the record.
- Determine whether the record remains active, queryable and segmentable in that state.
- Determine whether an event is emitted, and whether that event is on the platform's documented event surface.
- Identify the owner or queue that receives the handback — and note explicitly when there is none.
Where the end of a sequence emits an event, identity matters for the same reason it matters anywhere else: a producer must ensure `source` plus `id` is unique per distinct event so that a repeated delivery is recognisable as a duplicate rather than counted twice [cloudevents_spec]. Under at-least-once delivery the same terminal event can arrive more than once, so the handler must be idempotent for the outcome to match a single delivery [azure_resilient_event_design]. Where downstream handling repeats a write, whether that repeat is safe depends on the semantics of the operation [rfc9110_idempotent].
What checking the configuration establishes
| It establishes | It does not establish |
|---|---|
| Which status a sequence writes when it stops | That a different status would perform better |
| Whether the ended population is queryable at all | What that population is worth |
| Whether a handback owner or queue exists | That the handback is being worked |
| Which downstream systems can observe the ending | That any revenue or retention outcome followed |
The available terminal states and their downstream behaviour are defined by the specific platform in use and differ between products. Naming the concept does not recommend a setting.
Where this sits
The integration and orchestration systems guide owns the surrounding architecture, since a terminal state is the point where orchestration hands a process back. A missing return route for that handback is a write-back gap. This entry sits in the Glossary. Locate the capability under the Integration & Orchestration Systems domain, and use Revenue Scan when the next question is what public surfaces show.
Source and evidence notes
-
cloudevents_specCloudEvents specification, a graduated Cloud Native Computing Foundation project. It defines the required context attributes id, source, specversion and type, requires producers to ensure that source + id is unique for each distinct event, and states that consumers may assume events with identical source and id are duplicates. Limitation: A description and interoperability vocabulary only. It does not guarantee that any platform emits an event at the end of a sequence, and it does not describe any specific product configuration. -
rfc9110_idempotentIETF RFC 9110, "HTTP Semantics" (STD 97, June 2022), Section 9.2.2 "Idempotent Methods": a request method is idempotent if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request. Limitation: Defines HTTP method semantics only. It does not make any specific downstream handling safe to repeat. -
azure_resilient_event_designMicrosoft, "Resilient Design Guidance for Event Hubs and Functions," Azure Architecture Center. It states that at-least-once delivery means events can be received more than once and that a consumer must be idempotent so processing the same event multiple times has the same outcome as processing it once. Limitation: Platform-specific architecture guidance cited as a published example of at-least-once semantics. It does not describe the terminal-state behaviour of any particular product.