Triggers

A workflow's trigger is what fires it. Three trigger kinds exist: Document Analysed (the Initial_Workflow only), On field select (user-driven workflows), and a hidden internal trigger for system-shipped workflows.

This page covers each trigger type, how to configure them, and the timing nuances.

Document Analysed

Fires when the engine finishes extracting fields from a freshly-uploaded document. Used only by the project's Initial_Workflow — every project has exactly one, and you can't create others on this trigger.

In the Workflows page, Initial_Workflow's Triggers column shows No triggers. The binding is invisible — it lives in Recognito's Internal Mapping integration, configured when the project is created. You can edit the workflow's steps freely; you can't change its trigger.

What fires:

• Document upload via any channel (drag-and-drop, email, API).
• Once per document. No retries; if you change Initial Workflow steps, the change applies to newly-uploaded documents.
• After extraction completes. Specifically after the engine has populated initial field values, before the document appears in the queue.

For the full Initial Workflow treatment, see The Initial_Workflow.

On field select

Fires when a specific document field's value changes. This is the trigger type for user-driven workflows.

In the Workflows page, the Triggers column shows the field reference as <category>.<fieldName>:

• metadataFields.vendorName — fires when the reviewer picks a value in the vendorName Metadata field.
• tableFields.Item_erpItemDescription — fires when a line-item's Item_erpItemDescription is picked.
• mainFields.SubTotal — fires when SubTotal changes.

You configure the trigger field when editing the workflow. A workflow can watch multiple fields — any one of them changing fires the workflow.

Most workflows watch one field

Multi-field triggers are valid but uncommon. The typical pattern is one workflow per field — Vendor Select watches vendorName, Department Select watches departmentName, and so on. This keeps the firing model crisp.

Trigger timing — Select fields vs text fields

The timing of "On field select" depends on the field type:

Field type	Workflow fires when…
Select field	The reviewer picks a new option — immediate
Text field	The reviewer de-focuses the field (tabs out, clicks elsewhere)
Numeric field	Same as text — fires on de-focus
Date field	Same as text — fires on de-focus (likely; some date-picker UX may vary)

For Select fields, the click-to-pick is the commit. There's no de-focus step.

For text and numeric fields, the workflow waits until the field loses focus. This avoids firing the workflow on every keystroke as the reviewer types.

If you have a workflow watching a text field and noticed it doesn't fire while the reviewer is typing — that's by design. Wait for de-focus.

The hidden internal trigger (Approvers)

In some projects, Recognito configures a system-shipped workflow named Approvers that watches assignee changes. The trigger is configured via Recognito's internal admin panel and isn't visible or editable in the customer-facing UI. This is not part of the self-serve product — talk to your account manager if you need it.

In the Workflows page, this workflow's Triggers column shows No triggers — same as Initial_Workflow and same as any dead workflow. The UI doesn't distinguish them.

This is currently the only known hidden trigger. If your project doesn't have an Approvers workflow you didn't create yourself, you don't have this trigger.

When you see No triggers

Three cases:

1. Initial_Workflow — implicit Document Analysed trigger. Always present.
2. Approvers workflow — implicit assignee-change trigger. Only present if Recognito configured it (not self-serve).
3. Dead workflows — a workflow the customer created but never assigned a trigger to. Never fires.

For any No triggers workflow that isn't (1) or (2), it's almost certainly (3). Clean it up.

Dead workflows

The UI shows No triggers for both Initial_Workflow and any workflow created without configuring a trigger. There's no UI distinction, no warning, no count.

Dead workflows are easy to accumulate:

• An admin creates a workflow, sets up steps, gets pulled into another task, and never adds a trigger.
• An admin removes a trigger to "pause" a workflow and forgets to re-add it.
• A workflow that used to fire on a deleted field still shows in the list with no trigger.

Periodically scan your project's workflows for No triggers entries that aren't Initial_Workflow or a Recognito-configured Approvers workflow. They never fire — clean them up.

Multi-field triggers

A workflow can watch multiple fields. Any of them changing fires the workflow.

Example: a workflow that re-runs when any of customerInitials, vendorName, or Total changes. Useful for "re-compute everything that depends on these key context fields."

In practice, most customers prefer one workflow per field for clarity. Multi-field triggers can be harder to reason about (which field fired? what's the cascade?). Use them sparingly.

Trigger field types and workflow design

Some practical implications of trigger types:

Trigger field type	Use case
Select field (e.g., vendorName)	Standard user-driven workflows; reviewer picks a value, cascade fires immediately
Text/numeric field (e.g., SubTotal)	Workflows that should re-run when extracted values are corrected; fires on de-focus
Date field	Workflows depending on a date; fires on de-focus (typically)
Table field (e.g., Item_erpItemDescription)	Workflows that re-compute per-line data; fires per-row when that row's field changes

For Select-field triggers, the cascade is snappy — pick a vendor, wait 1–2 seconds, see the cascade results. For text-field triggers, the cascade waits for de-focus — finish typing, click elsewhere, wait 1–2 seconds.

What's next

• Steps and ordering — what happens after the trigger fires.
• The Initial_Workflow — the Document Analysed trigger in depth.
• Cascade rules — what doesn't fire (other workflows watching written fields).
• Async settling — the timing of trigger response.