Workflow Steps

This reference documents all available workflow step types and their configuration options in RiskOS™. Each step type represents a distinct action or logic block within a workflow.

Step types overview

Step type	Purpose	Async capable
Input	Define the evaluation payload schema	No
Enrichment	Call external data services and APIs	Yes (some providers)
Condition	Branch workflow logic based on data values	No
Advanced Condition	Complex multi-group conditional branching	No
Transformation	Manipulate and derive new data fields	No
Decision	Assign a final outcome (Accept, Reject, Review)	No
Manual Review	Route cases to a human review queue	No
Tag	Assign metadata labels to evaluations	No
Reason Code	Attach reason codes to explain decisions	No
Matrix Rule	Evaluate tabular rule sets	No
Rule Score	Compute risk scores from rule evaluations	No
Grouped Rules	Evaluate groups of related rules together	No
Wait	Pause workflow execution until a condition is met	Yes
OTP	Send and verify one-time passcodes	Yes
Hosted Flow	Trigger a Socure Hosted UX flow (e.g., Capture App)	Yes

Input

The Input step defines the data schema for the evaluation request payload. It is always the first step in a workflow.

Configuration	Description
Payload schema	Defines expected fields in the `data` object of the evaluation request
Field mapping	Maps incoming fields to internal workflow variables

📘
Note:
The Input step configuration is only visible for Socure-managed workflows. Custom workflows inherit the schema from the fraud type.

Enrichment

The Enrichment step calls a data service to add external signals to the workflow.

Configuration	Description	Required
Data service	The enrichment provider to call (selected from the dropdown)	Yes
Output field	Variable name where the API response is stored	Yes
Error output field	Variable name where error data is stored on failure	No

Enrichment step behavior

A workflow can include multiple enrichment steps, including consecutive ones.
Each enrichment call result appears in the data_enrichments array of the evaluation response.
For async-capable enrichments (for example, DocV), the workflow pauses until the enrichment completes and delivers results via webhook.

For a full list of available enrichments, see Integration Guides.

Condition

The Condition step branches the workflow based on data values using boolean logic.

Configuration	Description
Conditions	One or more condition rules evaluated against workflow data
Operator	Logical operator combining conditions: `AND`, `OR`, or `XOR`
True path	Steps executed when the condition evaluates to `true`
False path	Steps executed when the condition evaluates to `false`

Condition structure

Each condition rule is composed of:

Field	Description	Example
Left operand	Data field or expression to evaluate	`enrichment.emailRisk.score`
Operator	Comparison operator (equals, greater than, contains, etc.)	`>=`
Right operand	Value to compare against	`0.85`

Conditions can be grouped with AND, OR, or XOR logic, and groups can be nested for complex branching.

Advanced Condition

The Advanced Condition step supports complex multi-group conditional logic with nested condition groups and expressions.

Configuration	Description
Condition groups	Multiple condition groups with inter-group operators
Expressions	Advanced expression syntax for complex evaluations

Transformation

The Transformation step manipulates data within the workflow using spreadsheet-like functions.

Configuration	Description
Output field	Variable name where the transformed result is stored
Expression	Transformation logic applied to input data

Decision

The Decision step assigns a final evaluation outcome.

Configuration	Description	Required
Decision	Outcome value: `ACCEPT`, `REJECT`, `REVIEW`, or `RESUBMIT`	Yes
Reason codes	Codes explaining the decision	No
Tags	Metadata labels attached to the decision	No

📘
Note:
A workflow can contain multiple Decision steps on different branches, but only one executes per evaluation.

Manual Review

The Manual Review step routes the evaluation to a human reviewer in Case Management.

Configuration	Description	Required
Status	Initial case status: `OPEN` or `ON_HOLD`	Yes
Sub-status	Detailed status label	No
Queue	Review queue name for routing	Yes

Tag

The Tag step conditionally assigns metadata labels to evaluations.

Configuration	Description
Tag name	Label to apply (for example, "High Risk", "VIP Customer")
Conditions	Conditions that must be satisfied to apply the tag

Tags appear in the evaluation response tags array and are visible in Case Management for filtering and reporting.

Reason code

The Reason Code step conditionally attaches reason codes that explain evaluation outcomes.

Configuration	Description
Reason code	Code identifier (for example, `R001`)
Conditions	Conditions that trigger the reason code

Matrix Rule

The Matrix Rule step evaluates a tabular set of rules, where each row defines a combination of conditions and an output value.

Configuration	Description
Input fields	Data fields used as row/column keys
Output field	Variable name for the result
Output data type	`BOOL`, `INT`, `FLOAT`, or `STR`
Rule matrix	Table of input combinations mapped to output values

Rule Score

The Rule Score step computes a numerical score based on rule evaluations.

Configuration	Description
Rules	Set of conditions, each with an assigned point value
Output field	Variable name where the computed score is stored
Aggregation	How rule scores are combined (sum, weighted, etc.)

The computed score appears in the score field of the evaluation response.

Grouped Rules

The Grouped Rules step evaluates collections of related rules together, enabling modular rule management.

Configuration	Description
Rule groups	Named groups of conditions
Evaluation mode	How groups interact (all must pass, any must pass, etc.)

Wait

The Wait step pauses workflow execution until a specified condition is met or a timeout expires.

Configuration	Description	Required
Wait condition	Data condition that must be satisfied to resume	Yes
Timeout	Maximum wait duration before the workflow continues on the timeout path	Yes

When a Wait step is active:

The evaluation status changes to evaluation_paused.
You can resume the evaluation by sending a PATCH request with updated data.
A webhook event (evaluation_paused) is sent to subscribed endpoints.

OTP

The One-Time Passcode (OTP) step sends a verification code to the user and pauses the workflow until verification completes.

Configuration	Description	Required
Channel	Delivery method: `EMAIL`, `SMS`, or `VOICE`	Yes
Status	Case status while waiting: `OPEN` or `ON_HOLD`	Yes
Sub-status	Detailed status label	No
Queue	Review queue for timeout routing	Yes
Timeout	Maximum time to wait for verification	Yes
Output field	Variable name for the OTP result	Yes

Hosted Flow

The Hosted Flow step triggers a Socure Hosted UX experience (such as the Capture App for document verification).

Configuration	Description	Required
Flow configuration	Hosted UX template and branding settings	Yes
Timeout	Maximum time for the user to complete the flow	Yes

When a Hosted Flow step is active:

The user receives a link (via SMS, email, or QR code) to complete the hosted experience.
The workflow pauses until the user completes the flow or the timeout expires.
Results from the hosted flow are stored as enrichment data.

Workflow states and modes

Workflows themselves have states and modes that affect how they process evaluations:

Workflow states

State	Description
`DRAFT`	Workflow is being edited; not available for evaluations
`PUBLISHED`	Workflow is finalized and available for deployment
`DELETED`	Workflow has been removed

Workflow modes

Mode	Description
`LIVE`	Actively processing evaluations
`SHADOW`	Processes evaluations in parallel with the live workflow for comparison; results are logged but not returned
`AB`	A/B testing mode; traffic is split between this workflow and the live workflow
`TEMPLATE`	Serves as a reusable template for creating new workflows.