Triggers

A trigger is what causes a governed automation to consider firing. Every automation definition has one trigger. When the trigger occurs and the automation’s condition evaluates to true, the action runs.

Novantra’s automation module supports several trigger kinds. They’re deliberate; the trigger menu is what defines the surface area of what automations can react to.

Trigger kinds

Kind	Fires on
`schedule`	A clock-driven schedule (every day at 02:00, every Monday, the first of each month).
`governed-event`	A workspace event (record created, record updated, status transitioned, lifecycle transitioned).
`monitor-result`	A monitoring run result (pass, fail, warning, unknown).
`assessment-result`	An assessment completion.
`lifecycle-state`	A specific lifecycle state being entered or exited.
`evidence-state`	An evidence claim state transition (approved, rejected, expired).
`source-provider-fact`	A signal from an integrated source provider (a new CVE in a feed, a regulator publication).
`manual-request`	A manual fire by an authorized member, useful for testing and one-off runs.

Each trigger kind has its own configuration shape, and each is a first-class concept in the automation definition.

Schedule triggers

schedule triggers configure a recurring or one-off time when the automation should consider firing. Typical use:

Weekly KYC review checks.
Monthly attestation reviews.
Quarterly access recertification kickoffs.

Schedule triggers use a standard cron-like recurrence with timezone aware to your workspace timezone. Single-fire schedules are allowed for one-time automations.

Event-based triggers

governed-event triggers configure the automation to react when a specific kind of record changes. Typical use:

When a control transitions to non-compliant, request additional evidence.
When a finding closes, schedule a follow-up assessment.
When an evidence claim is rejected, re-route to a different reviewer.

The trigger configuration captures the module key, the resource type, and the event kind (created, updated, transitioned).

Result-based triggers

monitor-result and assessment-result triggers fire on the completion of a monitoring run or an assessment. Typical use:

When the daily privileged-access monitor reports any failure, open a finding.
When an annual access recertification assessment completes, route remediation findings to the IAM team.

The trigger configuration captures the specific monitor or assessment scope.

State-based triggers

lifecycle-state and evidence-state triggers fire on state transitions. Typical use:

When a party engagement enters terminating, request the wind-down checklist.
When an evidence claim approaches its validUntil, request a refresh.

External-signal triggers

source-provider-fact triggers fire on signals from integrated source providers. Typical use:

A new CVE relevant to your environment triggers a finding intake.
A regulator publishes a new rule and the integration ingests it; automation triages.

External-signal triggers depend on configured integrations and are surfaced through the workspace’s governed-facts layer.

Manual triggers

manual-request allows authorized members to fire an automation explicitly. Useful for:

Testing a newly-published definition.
Running a one-off check during an investigation.
Backfilling work after a definition is corrected.

Every manual fire is recorded with the requesting member.

A worked example: the credit union’s six triggers

The credit union’s six automations from the overview each use a different trigger shape:

Weekly KYC review check — schedule trigger, every Monday at 06:00. Checks for member accounts past KYC review-due.
Failed AML monitor follow-up — monitor-result trigger, on any failure result of the AML monitor.
Supplier attestation renewal — schedule trigger, monthly on the first business day. Checks for attestations approaching expiry.
Post-exception assessment — governed-event trigger, on exception record transition to closed.
Post-incident review check — governed-event trigger, on incident transition to closed.
Regulator rule change intake — source-provider-fact trigger, on new entries from the regulator-feed integration.

The trigger shapes determine the latency, frequency, and predictability of each automation. Schedule-driven ones are predictable but lag a few days. Event-driven ones are near-real-time but only fire when something happens.

Conditions

After a trigger fires, the automation’s condition is evaluated before the action runs. Conditions reference governed facts (e.g., account.kyc.daysSinceReview), evaluation projections (e.g., control.compliance from the canonical evaluation model), and subject references (the record the trigger is about). Conditions are declarative; they don’t run arbitrary code.

The credit union’s KYC review automation uses a condition: account.kyc.daysSinceReview > 365 AND account.status == "active". The schedule fires weekly; the condition filters to the accounts that actually need the action.

What you’ll see in the product

Inside an automation definition, the Trigger tab shows:

The trigger kind.
The trigger configuration (schedule, event filter, monitor scope, etc.).
The condition expression.
Recent triggering events with their resulting run outcomes.

Common workflows

Picking a trigger

Identify the signal that should cause the automation to consider firing.
Match it to one of the trigger kinds.
Configure the trigger and pair it with the appropriate condition.

Tuning a trigger

If the automation is firing too often (too noisy), tighten the condition.
If it’s firing too rarely, loosen the condition or pick a more frequent trigger.
Use dry-run preview to validate before changes go live.

Overview - the full automation suite.
Actions - what fires when the condition is true.
Runs - the execution evidence.
Monitoring - monitor results that trigger automation.