Custom Workflows
When a predefined workflow is close but not exact, a Company builds a custom one. Custom workflows are composed from the same vetted building blocks — Companies configure and arrange them declaratively; they never write executable code.
Fork, then edit
A custom workflow starts as a fork — a copy of a predefined workflow. From that point it is independent: later changes to the original do not flow into the fork automatically. This keeps behavior predictable and easy to reason about.
What you can customize
| Aspect | Examples |
|---|---|
| Step sequence | Add, remove, or reorder capture and evaluation steps from the catalog, including emit_event steps that notify your backend at any point of the flow. |
| Step parameters | Retry counts, timeouts, allowed document types, which Trust Factor profile to use. |
| Conditional branches | Decide the next step or the outcome based on earlier results. |
| Outcome actions | Which record actions run for each named outcome (create/merge Customer, watchlist changes). |
Conditions
Branch logic is expressed with CEL (Common Expression Language) — a small, sandboxed, widely-used expression language. A rule's condition reads the results collected so far, for example:
tf_eval.result == 'accept' && matching.result == 'match'
Comparisons are combined with &&, || and parentheses; && binds tighter than ||. The supported subset is described in Condition syntax.
The condition determines which named outcome a decision produces. The first matching rule wins and ends the workflow in the rule's terminal state; an optional default handles the "no rule matched" case and can let the workflow continue.
Authoring, validation, and publishing
- Workflows are authored in the dashboard by users with the Administrator or Supervisor role; other roles see them read-only.
- Before publishing, a workflow is validated — schema correctness, that every referenced step type, Trust Factor profile and outcome resolves, and that conditions and event references are valid (see Validation).
- Publishing takes effect immediately for new sessions; sessions already running finish on the version they started with.
- Workflows are scoped per tenant — one Company's workflows never affect another's.