Workflow Steps
Explore the building blocks of RiskOS™ workflows, including input, enrichment, condition, transformation, decision, and tagging 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_enrichmentsarray of the evaluation response. - For async-capable enrichments (e.g., DocV, Plaid), 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
PATCHrequest 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 |
Related
Updated about 1 month ago