## Use cases

- **Pending data**: Pause until an external service provides required values (e.g., internal API, verification result).  
- **Custom backend triggers**: Resume workflows when your system calls the API after downstream processing.

## Configure a Wait step

1. Select the **Wait step** in the workflow canvas to open the side panel.  
2. Configure the **Wait queue** settings. Entities that do not meet the resume conditions will remain paused in this queue until resumed:  
   - **Status** → The case status applied while waiting.  
   - **Sub-status** → The sub-status applied for additional categorization.  
   - **Queue** → The queue where paused cases are placed.  
3. Define the **resume condition**:  
   - Example: _Resume if `document_id` is not empty_.  
   - This ensures the workflow only continues when the API call provides the expected data.  
4. Specify the **output field**:  
   - Each Wait step creates a **Boolean** output (`true` / `false`).  
   - This output can be checked in subsequent steps to confirm whether the Wait condition was met.  
5. (Optional) Customize the Wait step’s **label** in the side panel for clarity.

## Resume behavior

- **API-first design**: A workflow paused at a Wait step must be resumed through an API **PATCH** call.  
  
  - The call must reference the **evaluation ID** of the workflow instance to be resumed and include the required data.  
  - See the [API reference](https://help.socure.com/riskos/reference/postevaluation#/) for details on request format and payload fields.  
- **Case Management**: In some scenarios, workflows can also be resumed from the Case Management interface, but no new data can be added this way.  
- **Resume conditions**: If the resume condition evaluates to **False** (e.g., a null field), the workflow remains paused until the correct data is received.

## Best practices

- **Use sparingly**: Avoid adding unnecessary Wait steps to reduce workflow complexity.  
- **Design meaningful resume conditions**: Always tie the condition to a concrete event, such as “field is not null” or “value equals true.”  
- **Monitor paused workflows**: Ensure you have monitoring and alerts to track workflows waiting for external triggers.  
- **Multiple Wait steps**: Workflows may include more than one Wait step, but each must have a clearly defined resume trigger.  
- **Fallback strategies**: Define what should happen if the external trigger never arrives (e.g., timeout logic handled in your system).  
- **Webhooks**: If a workflow reaches a Wait step **after being resumed** (e.g., two consecutive Wait steps, or a Wait step followed by a DocV step), the system will send a **webhook** notifying downstream systems that the workflow resumed but is again paused.  
  
  - Build logic to handle these scenarios properly.

## Notes

- Wait steps are meant for **asynchronous flows** that need specific data input.  
- The **resume condition** is essential — without it, workflows may remain indefinitely paused.  
- The system currently does **not** allow you to configure a timeout that automatically resumes a workflow.  
  
  - It is the customer’s responsibility to resume the workflow after a specific time.  
  - If no action is taken, the workflow will remain paused indefinitely.