Runs
Every execution of a governed automation produces a run: a record of when the automation fired, which trigger event caused it, which subjects matched the condition, which actions were invoked, what each action returned, and where the resulting records (findings, evidence requests, lifecycle transitions, etc.) landed.
A run is the audit-grade evidence of automated work. When something needs to be reviewed — by an auditor, by the team itself, by a regulator — the run is the artifact.
When you would reach for this
You look at runs when:
- An automation is firing more or less than expected and you need to see what’s happening.
- A failed run needs investigation: which actions failed, with what cause.
- An auditor wants the trail of what automation actually did over a period.
- A retry decision is needed after a transient failure was corrected.
You don’t reach for this for the actions’ downstream effects themselves. The created findings, requested evidence, opened lifecycle instances live in their owning modules. Runs are the upstream record that links automation to those downstream records.
What lives in a run
Two record types:
Run is the execution itself. It carries:
- The automation definition (with the version that was in effect).
- The trigger event (timestamp, source).
- The status (
pending,running,completed,completed-with-failures,cancelled,failed). - The subjects matched count and the actions invoked count.
- The started-at and completed-at timestamps.
Run item is one action-on-subject within the run. A schedule-triggered automation that finds 14 matching subjects produces a run with 14 run items, one per subject. Each item carries:
- The subject (the record the action was taken on or about).
- The action invoked and its parameters at this point in time.
- The outcome:
succeeded,failed,skipped(condition didn’t apply),awaiting-approval,idempotent-replay. - The resulting record reference (e.g., the finding ID that was created).
- The failure cause (if failed).
Run statuses
| Status | Meaning |
|---|---|
pending | Created but not yet started. |
running | In progress. |
completed | All items completed successfully. |
completed-with-failures | Some items failed; the run as a whole is closed. |
cancelled | Cancelled by an authorized member before completion. |
failed | The run as a whole failed (e.g., the actioner module was unreachable). |
Run item outcomes
| Outcome | Meaning |
|---|---|
succeeded | The actioner returned success; the downstream record was created/updated. |
failed | The actioner returned a failure. The cause is recorded. |
skipped | The condition didn’t hold for this subject; no action attempted. |
awaiting-approval | The action requires review-approval; the approval instance is in flight. |
idempotent-replay | A retry was attempted with the same idempotency key; the original outcome is returned. |
A worked example: the credit union reviews automation activity
Three months after activating the six automations from the overview, the credit union’s compliance officer Sigrid walks through the runs.
The weekly KYC review automation. Over the quarter, 13 runs (one per week). Each run found between 30 and 80 accounts past KYC review-due. Each run created evidence requests routed to the relevant account managers. Total items across the quarter: ~620. Outcomes: 590 succeeded, 12 skipped (accounts that became inactive between the trigger and execution), 18 awaiting-approval-from-retry (the integration to the messaging system that delivers the request had a transient outage; items recovered on retry).
The AML monitor failure automation. 23 runs over the quarter (one per failure result of the AML monitor). Each run created one finding. Total: 23 findings, all succeeded. The findings now live in the Findings register with their own remediation lifecycle.
The supplier attestation renewal automation. 3 runs (one per month). Each found between 5 and 15 suppliers approaching attestation expiry. Total items: 28, all succeeded.
The post-exception assessment automation. 7 runs (each fired on an exception closure event). All 7 scheduled assessments succeeded.
The post-incident review check automation. 9 runs (each fired on incident closure). 7 cases the review record already existed (skipped); 2 cases it didn’t (action requested approval; approval granted; finding created to track the missing review).
The regulator rule change intake automation. 4 runs over the quarter (each fired by an integration signal). All 4 went through approval; 3 finding-creates approved, 1 dismissed by the compliance officer as not applicable.
Sigrid produces a brief for the next audit committee meeting summarizing: 59 runs across the quarter, 678 actions invoked, 0 unintended consequences. The audit-grade trail per run is reachable for any specific case the committee asks about.
Retries and idempotency
When a transient failure causes a run item to fail, the failure cause is recorded and the item enters a retry-eligible state. The run as a whole moves to completed-with-failures (or stays running, depending on configuration). Authorized members can initiate a retry from the run; the retry uses the same idempotency key, so the action isn’t double-executed if the original actually succeeded but the response was lost.
For deterministic failures (the condition no longer holds, the actioner refuses), retry isn’t useful and the item stays failed with a clear cause.
Cancellation
A run in progress can be cancelled by an authorized member. Items that haven’t started yet are skipped; items in flight complete (idempotent) and their outcomes are recorded. Cancellation is recorded in the audit trail.
What you’ll see in the product
The Runs tab under Governance → Automation is filterable by definition, status, date.
Inside a run, you see the trigger event, the matched subject count, the action breakdown, the items list with outcomes.
Inside a run item, you see the subject, the action parameters at execution time, the outcome, the resulting record reference (with deep link), the failure cause if applicable.
Every record is captured in the workspace Audit Log.
Common workflows
Reviewing recent activity
- Filter Runs by date range.
- Sort by completion time.
- Look for runs in
completed-with-failuresorfailedstatus for attention.
Investigating a failed item
- From the run, open the failed item.
- Examine the failure cause.
- Address the underlying cause (transient upstream issue, condition assumption that no longer holds, parameter that resolves to an invalid value).
- Retry if appropriate; or fix the automation definition and let the next trigger fire normally.
Auditing a quarter’s automation
- Filter Runs by date range.
- Group by definition.
- Pull counts per outcome.
- For unexpected counts, drill into specific runs.