Creating and editing a flow

Previous Next

The Flow Detail page is the flow builder. It is where an existing flow is named, arranged into document steps, given profile variables, and supplied with automated checks.

Route: /flows/<flow-id>/

Example:

https://default-company.localhost/flows/964047a6-e409-41c4-a9d5-47db9f52985d/

The UUID identifies one flow. A URL from one company hostname does not imply access to the same UUID in another tenant.

The header displays the flow name, description, active state, and totals for Steps, Profile Variables, and Cross-Document Checks.

The actions are:

  • Runs: opens the Runs list filtered to this flow.
  • Edit: changes the flow name, description, and Active setting.
  • New Run: creates one application run from this flow.

The New Run form asks for a reference and application date. It may also show profile variables configured to be collected when a run is created. After creation, the run opens in the document-collection phase.

Steps

A Step is one document requirement in the flow. Steps appear in order and are grouped by bundle. Open a Step card to see its accepted document types and configuration.

Select Add Step to configure:

Field Meaning
Document requirement The requirement filled by this Step. Any accepted document type on the requirement can satisfy it. A flow cannot contain the same requirement twice.
Order Controls display order. Values such as 10, 20, and 30 leave room between Steps.
Bundle Groups related Steps under a shared heading. An empty bundle appears as Ungrouped.
Core step Normally required for every run. A condition can still exclude it; an unanswered condition keeps a core Step required.
If required document is missing Recommends Proceed, Send back, Flag to officer, or Recommend rejection.
Required when Uses profile variables to decide whether the Step belongs in a run's manifest. Empty means unconditional.
Defer when Marks a missing requirement as deferrable when its condition matches.
Depends on Records which existing Steps come before this one. It does not add an Application Progress phase.
Reviewer notes SOP guidance displayed beside the requirement on a run.

Conditions can use is, is not, is one of, is yes, is no, and is answered. Multiple rows can require ALL or ANY of the conditions. The JSON mode supports more complex rule expressions.

These conditions decide whether a document belongs in the run; they do not validate the contents of an uploaded document. See How validation works for the distinction between manifest, field, document-rule, and cross-document validation.

The current runtime records and displays Depends on, but manifest resolution does not yet use it to block or sequence a Step. Treat it as descriptive dependency metadata for now.

Open a saved Step and select Edit step to change it. The document requirement is fixed for that Step; remove and recreate the Step if the requirement itself is wrong. Remove step deletes the Step from the flow.

Note

The Application Progress bar on a run is a fixed five-phase lifecycle. It does not create one progress circle per configured Step. See Run Detail.

Profile Variables

Profile variables are application facts used by Step conditions and profile reconciliation. The table shows:

  • the machine name and readable label;
  • whether the value is operator-defined or derived;
  • its value type;
  • its available choices; and
  • the document field or strategy from which a derived value is obtained.

Select Add Variable to enter a label, machine name, type, optional choices, optional source document field, and description.

Value types are:

  • Yes / No;
  • Choice, with one value | Readable label entry per line; and
  • Free text.

The source document list contains only document types accepted by Steps in this flow. Add the relevant Step before configuring an automatically derived variable.

The current table provides a remove action. It does not expose an inline edit form for an existing variable, so take care when naming variables used by conditions.

Cross-Document Checks

Cross-document checks compare extracted facts from two or more documents. Select Add Check to configure:

Field Meaning
Key A unique stable identifier such as K01.
Name A readable title for the comparison.
Match type Exact, Fuzzy, Range, Signature, or External system. See Cross-document match types for how each is compared.
Severity Block or Flag.
Mismatch action The recommended outcome if the values disagree.
Description What the check verifies.
SOP reference The governing procedure section.
Active Only active checks run. New checks are active by default.

After creating a check, open it and add field sets. A field set selects either:

  • one document type and one or more extracted fields; or
  • one or more resolved Profile Variables.

Multiple values are joined, for example given names plus surname. Use reference when one field set is the authoritative target period or value that the other sources must cover.

Checks and their field sets can be edited or removed. Removing them changes future processing and reprocessing of runs.

For guidance on choosing between a field constraint, Step condition, per-document rule, and cross-document check, see Where should a new rule live?.

Use Run when to limit a check to the relevant profile, for example running a residence-card number check only for renewals. The NIDMS pattern is shown in Advanced NIDMS identity check.

Manifest Preview

Manifest Preview tests the flow without creating a run. Choose sample answers for the profile variables and select Preview manifest.

Each Step receives one verdict:

  • Required;
  • Required · deferrable;
  • Not required; or
  • Undecided because an answer is missing.

The Why column shows whether the decision came from a core Step or a condition. Preview does not upload, extract, validate, or cross-check any documents.

For a guided example, see Create your first document flow.

Flows Runs