Actions

An action is what a governed automation does when its trigger fires and its condition is true. Actions are not arbitrary code. They are calls to registered actioners owned by other modules. A finding actioner creates findings. An evidence actioner requests evidence. A lifecycle actioner proposes a lifecycle transition. The full set of what automations can do is the set of registered actioners across the workspace.

This is the design property that makes automation safe to entrust with governance work: actions are finite, named, owned by accountable modules, and reviewable as a catalogue.

When you would reach for this

You configure actions when:

A new automation needs to do something — picking the actioner is the heart of the definition.
An existing automation needs its action changed (a different actioner, different parameters).
You’re evaluating whether automation can support a workflow — the question becomes “is the action I need an existing actioner?”

You don’t reach for this for actions that don’t exist as registered actioners. If your workflow needs an action that isn’t exposed, the answer is either to wait for the actioner to be exposed or to fall back to a human task.

The actioner catalogue

Modules expose registered actioners. A non-exhaustive selection of what’s available across the workspace today:

Actioner	Owning module	What it does
`findings.create`	Findings	Creates a finding with subject, severity, source, owner.
`findings.update-status`	Findings	Transitions a finding’s status.
`evidence.request-claim`	Evidence	Requests an evidence claim from a named owner against a requirement.
`evidence.approve-claim`	Evidence	Approves a pending claim.
`risks.create-candidate`	Risks	Creates a risk candidate for triage.
`assessments.schedule`	Assessments	Schedules an assessment of a specific subject.
`submissions.create-event`	Submissions	Records a submission event on a package.
`lifecycle.propose-transition`	Governed Lifecycle	Proposes a lifecycle transition for a subject.
`responsibilities.assign`	Responsibilities	Assigns a responsibility to a member or role.
`notifications.send`	Notification system	Sends a notification to a configured channel.
`incidents.intake`	Incidents	Creates an incident intake record.
`violations.intake`	Violations	Creates a violation intake record.

Each actioner has documented parameters, permission requirements, and idempotency semantics. The full catalogue is browsable in the in-product Actions surface.

Why actioners and not code

Three reasons:

The owning module enforces its truth. When findings.create is called, the Findings module decides whether the record is valid, applies its own validation, raises the appropriate domain events. The automation module never bypasses that.
The set is reviewable. An auditor can be shown the full list of actioners. There’s no hidden surface where an automation might do something unexpected.
Permission and policy gates apply. The actioner enforces the same permission checks that a human action would. An automation can’t escalate beyond what its owning service account is permitted to do.

This is the contract that makes “let an automation do this” something you can say with confidence.

Action parameters

Each actioner takes parameters. Parameters can be:

Literal: a value the definition author provides (e.g., severity = “high”).
Subject-derived: pulled from the trigger’s subject (e.g., the subject’s ID, the subject’s owner).
Condition-derived: computed from the condition evaluation (e.g., the failing items from a monitor result).
Context-derived: from the broader execution context (e.g., the current quarter, the workspace timezone).

The actioner documents which parameters are required and what shapes they accept.

Review-approval gates

Some actions are too consequential to fire autonomously. For these, the automation definition can require review-approval before action. When the trigger fires and the condition is true, instead of invoking the actioner directly, the automation creates a review-approval instance routed to the configured approver. On approval, the action proceeds. On rejection, the action does not.

Examples of when to require approval:

Anything that creates a customer-visible record.
Anything that affects a large number of subjects in one call.
Anything that escalates to leadership.
Anything destructive (close, archive, revoke).

The credit union’s regulator-rule-change automation requires approval: the compliance officer reviews the proposed finding before it’s created, because creating a regulator-attributed finding has organizational weight.

A worked example: the credit union’s six actions

The credit union’s six automations from the overview bind to six different actioners:

Weekly KYC review check → evidence.request-claim with the relevant account manager as the requested owner.
Failed AML monitor follow-up → findings.create with severity from the monitor’s reported severity, owner = AML lead.
Supplier attestation renewal → evidence.request-claim to the supplier’s relationship manager.
Post-exception assessment → assessments.schedule against the control linked to the exception.
Post-incident review check → findings.create (if no review record exists) requesting review-approval before the finding is created.
Regulator rule change intake → findings.create requesting review-approval (the compliance officer signs off before the finding is created).

The six show the pattern: pick the actioner that fits, parametrize it from the trigger, decide whether review-approval is required.

Dry-run preview

Before any execution, automation definitions support dry-run preview. A preview walks the trigger and condition with current workspace state, identifies what action would be taken on each matching subject, and shows the planned parameters — without invoking the actioner. The preview is the validation step that catches misconfigured conditions and unintended targets.

Idempotency

Each action invocation carries an idempotency key derived from the trigger context and subject. Retries (on transient failure, on operator-initiated retry from the run) use the same key, so the action isn’t double-executed. Actioners that support idempotency natively (most do) honor the key.

What you’ll see in the product

Inside an automation definition, the Action tab shows:

The chosen actioner and its owning module.
Configured parameters and their sources.
Review-approval requirement (if any).
Permission scope of the service account the automation runs as.

The cross-cutting Actions catalogue lists every registered actioner browsable.

Common workflows

Picking an actioner

Identify the action your automation needs to take.
Browse the actioner catalogue.
If a matching actioner exists, configure parameters.
If not, raise the request with your account team; the corresponding module owner exposes the actioner.

Configuring an action

Pick the actioner.
Configure required parameters; reference subject/condition/context sources where appropriate.
Decide on review-approval requirement based on action consequence.
Run dry-run preview.

Tightening to review-approval

From the definition, change the action to require approval.
Configure the approver routing.
The next execution will create a review-approval instance instead of invoking directly.

Overview - the full automation suite.
Triggers - what fires before the action.
Runs - execution evidence per action.
Findings - common action target.
Evidence - common action target.
Review-Approval - the gate when required.