These cookies are required for the website to function properly. They ensure security, enable basic features like page navigation, and store user session data. You cannot disable these cookies.
- Workflow Automation Engine
- Features
- Durable execution
Durable execution
Connect each execution to its source record, revision and lasting run result.
OverviewExecution outcomes×
Workflow Automation Engine · Durable execution
New
Execution outcomes
Automation executions
| Parent | Source record id | Outcome | Started at | Execution result | |
|---|---|---|---|---|---|
| AD-13614 | SRI-818 | Pending | 04 Oct | ER-750 | |
| AD-62204 | SRI-380 | Accepted | 06 Oct | ER-865 | |
| AD-11467 | SRI-502 | Pending | 21 Oct | ER-525 | |
| AD-64661 | SRI-747 | Accepted | 22 Oct | ER-619 | |
| AD-42175 | SRI-374 | Pending | 22 Oct | ER-532 |
6 of 6 records
SRI-818Automation executions · AE-53401
PendingParentAD-13614
Started at04 Oct
Execution resultER-750
What you can do
Know what actually ran
The execution workflow starts from a reviewed revision and persists an execution, an operation run, a confirmed step receipt and an execution attempt. It marks the run Succeeded after confirmed output and updates the definition’s execution result. The Operations Operator can follow that path from the source record to the outcome without treating a visible status as the whole proof.
The source record identifier is required on an execution. The definition version and operation key let the team compare the intended input with the operation that was carried out. Keep the parent definition linked to the run. A later definition revision should not make an earlier execution look as though it used the new instructions.
How the work is organized
- Execution. The source identifier and parent definition establish what request was processed.
- Operation run. The key, revision, status and result reference record the durable operation.
- Confirmed output. The step receipt and result carry the evidence needed to assess success.
What to agree during setup
Define where source identifiers come from and how the team handles repeated requests. Decide whether the provider reference or result reference is the external reconciliation key. Set a retry policy on the definition that the Operations Operator understands before starting a run. Agree which failed or uncertain outcomes require investigation rather than another immediate attempt.
Choose a pilot source record that can be checked in the connected service. Keep its input schema and definition version. After execution, compare the local result with the outside receipt and record the business outcome on the execution. If the result differs, use the run and step trace to locate the gap before another action is taken.
Check the handoff on an actual case
A reviewed definition processes a request that has a stable source record identifier. The Operations Operator starts its run and later checks the accepted outcome against the operation result reference. The corresponding step has an external receipt, and the attempt shows when the provider call finished. The definition’s latest result gives the owner a quick summary, while the linked records explain how it was reached.
Now rehearse a repeated request with the same source identifier and operation key. The team should inspect the prior run and receipt before deciding whether another attempt is safe. If the provider outcome is uncertain, record the exception for reconciliation. Do not infer a successful external action solely from a local status.
What your team sees
- Execution outcomes — Match each source record to its parent definition and recorded outcome.
- Run status board — Find queued, running, successful and exceptional operations.
- Runs requiring attention — Investigate failures and reconciliation work with the original key.
Follow the work through
Read durable execution and receipt and exception review for the run and its evidence.
What it keeps track of
Data model- Automation definitions
- Defines one automated process teams can trigger, showing its steps, status, and latest run outcome.
- Automation executions
- Represents one run of an automation, showing what happened, the quantities involved, and the result.
- Operation runs
- Represents one run of an operation, used to track its progress, timing, and outcome.
- Operation steps
- Represents one step in a run, letting teams see progress and spot exactly where it failed.
- Execution attempts
- Tracks one attempt to run an operation, helping teams see retries, timing, and failures.
Who uses it
Permissions- Operations Operator
- , Automation Owner, Audit Reader.
Set up Workflow Automation Engine your way.
Start free, then use Proto to change fields, steps and approvals before your team goes live.