Appearance

Cascade behavior ​

Workflows execute their steps in declared order. Each step's writes are visible to subsequent steps within the same workflow run. Workflows do not trigger other workflows — only their own configured trigger fires them.

Cascade is the most consequential rule for designing workflows. Misunderstanding it produces broken cascades that look mysteriously stuck.

The cascade rules ​

Steps run in declared order ​

A workflow's steps are an ordered list. When the workflow fires, the steps run from first to last. Reordering steps in the editor changes execution order on the next run.

Sequential feed-through ​

Each step writes to document fields. Subsequent steps in the same workflow see those writes.

Example: a workflow's step 1 sets vendorAccount based on a vendor lookup. Step 2's Context references vendorAccount. When step 2 runs, it sees the newly-written vendorAccount from step 1, not whatever was there before.

This is how composite lookups across multiple definitions work. Step 1 establishes some context; step 2 uses that context for a more specific lookup.

Workflows don't trigger other workflows ​

A step that writes to a Select-type field updates that field's value but does not fire the workflow watching it.

Concrete: if you have a Vendor Select workflow with a step that writes itemDescription, and a separate Header Product Select workflow whose trigger is metadataFields.itemDescription, picking a vendor doesn't chain into Header Product Select. The trigger is reserved for user actions — a reviewer picking a value in Studio — not programmatic writes from another workflow.

No cross-workflow cascade

This is the single most common source of "the cascade didn't fire" confusion. To get a cross-workflow cascade effect, you don't chain workflows. You inline all the relevant definitions as steps in one workflow.

How customers compose around this ​

Two patterns recur:

The all-in-one workflow ​

A user-driven workflow includes every effect picking that field should produce — even effects that "feel like" they should belong to other workflows.

Example: a Vendor Select workflow watches vendorName. Its steps include:

  1. The vendor lookup itself (sets vendorAccount, currency, VendorId).
  2. Header Products initialization (sets itemDescription dropdown and value).
  3. Accountant and warehouse lookup (sets accountant, warehouse).
  4. Item Products dropdown initialization (per-line-item).
  5. Item Products mapping (per-line-item).

Five steps in one workflow. If the customer had instead expected a separate Header Product Select workflow to chain off step 2's write, they'd end up with a half-populated document because that chain doesn't happen.

Mirroring the Initial Workflow ​

User-driven workflows often re-run a subset of Initial_Workflow's steps when their trigger field changes.

If Customer Initials Select fires (because the reviewer changed customerInitials), it typically re-runs Approvers, Initialize Products, Header Product Select, and Item Product mapping — all the chunks of Initial_Workflow that depend on customerInitials. The customer picks the subset of steps that need re-running and inlines them in the user-driven workflow.

The order-matters trap ​

Steps in a workflow are sensitive to ordering because of sequential feed-through. Reordering steps without thinking about Context dependencies produces silent breakage:

  • Earlier steps may silently no-op (their Context wasn't yet established by an even-earlier step).
  • Later steps may use stale values (a step that should have run after the trigger update ran before it).

The defensive approach: when adding a step, place it after every step it depends on for Context values. When the dependency chain is long, sketch the dependencies before reordering.

The dead-workflow trap ​

The Workflows page shows No triggers for two different things:

  • The Initial_Workflow (whose Document Analysed trigger is implicit and not customer-visible).
  • Workflows the customer created without configuring a trigger field.

The UI doesn't distinguish them. A dead workflow with No triggers will never fire — but you won't get a warning. Periodically scan your project's workflows for No triggers rows that aren't Initial_Workflow and clean them up.

What about the Approvers workflow? ​

There's one third case for No triggers: the system-shipped Approvers workflow in some projects has a hidden internal trigger — assignee change, configured via Recognito's admin panel, not exposed in the customer-facing UI. This is not part of the self-serve product; talk to your account manager.

This is the exception. If your project has an Approvers workflow showing No triggers and you weren't expecting one, talk to Recognito support before deleting it.

Cascade and the empty-cell rule ​

When a step in a cascade writes nothing (because the matched entity row has an empty cell), the document field keeps its old value. The next step sees that old value, not nothing.

This is sometimes intentional: a workflow's step might intentionally leave fields unwritten if the entity row doesn't have updates for them. The next step then operates on the unchanged context.

For more detail, see The empty-cell rule.

Cascade and silent no-ops ​

If a step's lookup finds no matching entity row, the step is a silent no-op — nothing writes, nothing errors. The next step in the cascade runs with the unchanged state.

This is the most common reason cascades "don't do anything visible." The cascade ran; the step just had no row to match. Add the missing row to the entity, configure a Fallback, or widen the Context.

What's next ​