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](https://help.socure.com/riskos/docs/workflow-steps#input) | Define the evaluation payload schema | No | | [Enrichment](https://help.socure.com/riskos/docs/workflow-steps#enrichment) | Call external data services and APIs | Yes (some providers) | | [Condition](https://help.socure.com/riskos/docs/workflow-steps#condition) | Branch workflow logic based on data values | No | | [Advanced Condition](https://help.socure.com/riskos/docs/workflow-steps#advanced-condition) | Complex multi-group conditional branching | No | | [Transformation](https://help.socure.com/riskos/docs/workflow-steps#transformation) | Manipulate and derive new data fields | No | | [Decision](https://help.socure.com/riskos/docs/workflow-steps#decision) | Assign a final outcome (Accept, Reject, Review) | No | | [Manual Review](https://help.socure.com/riskos/docs/workflow-steps#manual-review) | Route cases to a human review queue | No | | [Tag](https://help.socure.com/riskos/docs/workflow-steps#tag) | Assign metadata labels to evaluations | No | | [Reason Code](https://help.socure.com/riskos/docs/workflow-steps#reason-code) | Attach reason codes to explain decisions | No | | [Matrix Rule](https://help.socure.com/riskos/docs/workflow-steps#matrix-rule) | Evaluate tabular rule sets | No | | [Rule Score](https://help.socure.com/riskos/docs/workflow-steps#rule-score) | Compute risk scores from rule evaluations | No | | [Grouped Rules](https://help.socure.com/riskos/docs/workflow-steps#grouped-rules) | Evaluate groups of related rules together | No | | [Wait](https://help.socure.com/riskos/docs/workflow-steps#wait) | Pause workflow execution until a condition is met | Yes | | [OTP](https://help.socure.com/riskos/docs/workflow-steps#otp) | Send and verify one-time passcodes | Yes | | [Hosted Flow](https://help.socure.com/riskos/docs/workflow-steps#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](https://help.socure.com/riskos/docs/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.