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. The fork records which workflow it came from for reference.
What you can customize
| Aspect | Examples |
|---|---|
| Step sequence | Add, remove, or reorder capture and evaluation steps from the catalog. |
| 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, custom events). |
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'
The condition determines which named outcome a decision produces. First matching rule wins; an optional default handles the "no rule matched" case.
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 / document set resolves, that expressions parse, and that every path reaches a valid outcome.
- 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.