## When to use workflow testing

- **Validate against historical data** before deployment.
- **Analyze hypothetical outcomes retroactively**.
- **Simulate edge cases** by running tests with custom JSON payloads.
- **Run regression checks** after making workflow changes.
- **Experiment safely** in a controlled environment.

> 📘  
> **Note**:  
> **Workflow testing is now disabled** for workflows that include any **asynchronous** steps (for example, **DocV**, **OTP**, **Wait step**) or **asynchronous data services**.  
> This is a temporary limitation we plan to lift in **Q4 2025**. If you need to test such workflows today, we can provide **synchronous drop-in replacements**. Please work with your **Solutions Consultant** or email **[support@socure.com](mailto:support@socure.com)** for details.

## Testing modes

RiskOS™ supports two types of testing:

- **Historical evaluations**: Previously processed records are re-executed against the workflow.
  - No live decisions or cases are created.
  - Results are available for analytical comparison.
- **Custom JSON payloads**: Input a single JSON object to simulate a scenario.
  - Ideal for debugging or validating behavior with synthetic data.
  - Results are immediate but lightweight — there is no persistent storage and responses cannot be opened in Case Management.

### 1\. Run a workflow test

1. Save your workflow draft.
2. Click **Run a backtest** in the **Workflow Canvas**.
3. Choose an input method:
   - **Select cases from a list**: Pick from your RiskOS™ account by ID or date range.
   - **Input Cases IDs**: Enter up to 100 IDs (comma-separated).
   - **Use custom data input**: Paste a JSON payload into the input field.
4. Click **Run Test** to begin.

### 2\. Interpret the results

When testing with multiple IDs or historical cases, a **Test Results panel** is shown.

#### Evaluations completed

Shows how many test cases were evaluated **without workflow errors** vs. those with issues.

#### Comparative outcome chart

A bar graph compares:

- **Previous Outcome** → The original workflow’s decision.
- **Test Outcome** → The updated workflow’s decision.

#### Evaluation results table

For each ID tested, the table displays:

- The decision from the original workflow.
- The decision from the updated workflow.

Click the **>** icon to drill into step-by-step execution details.

## Limitations

- Live workflows cannot be backtested — clone into a new minor version first.
- When testing with a **single custom JSON payload**, the comparative results panel is not shown.
- Test results cannot currently be **exported or downloaded** (JSON, CSV, etc.).

> 📘  
> **Note**:  
> **Testing may use cached enrichment results.**  
> If the same **evaluation ID** was used in past runs, enrichment responses are reused.
> - Adding a new service or renaming a step bypasses the cache and may trigger new calls, potentially incurring **additional costs**.
> - A pop-up will ask you to confirm before costs are applied.
> - To avoid cached responses entirely, provide a **new evaluation ID**.

# Best practices

- **Test iteratively**: Run small sets of IDs or synthetic cases before large-scale backtests.
- **Check error cases**: Review both “completed” and “completed with errors” results to spot workflow misconfigurations.
- **Validate deltas**: Focus on how outcomes differ between the original and updated workflows.
- **Document limitations**: Remember that test results are view-only; keep separate notes if you need a record.
- **Interpret errors carefully**: RiskOS™ often completes workflows even if individual steps throw errors.

- A red error symbol in the side panel usually means a missing or null field.
  - Many such errors are expected and not harmful (e.g., null values used in conditions).
  - Pay special attention to errors from data services and confirm they returned a valid API response.