Wait Step

The Wait step pauses a workflow until an external signal resumes the process and specific conditions are met. In RiskOS™, Wait steps are primarily designed to be resumed via an API PATCH call, though limited resume actions may also be triggered from Case Management.

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 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.

📘

Note:

The Wait step is available behind a feature flag. If you cannot see the Wait step in your Workflow Builder, please contact [email protected] to have it enabled.