Wait For Condition action
-
- UpdatedAug 14, 2024
- 7 minutes to read
- Xanadu
- Create Workflows
Pause a flow until record values match a specific set of conditions.
Roles and availability
Available as a Workflow Studio ServiceNow core action. Users with the flow_designer or admin role can add an action to a flow and define configuration details.
Inputs
Provide a value for each input that your flow needs. To add dynamic values, you can also drag and drop pills from the Data panel or select them from the pill picker.
- Record
- Data type: Record
The record whose field values the action monitors for changes. This record can come from a flow trigger, a subflow input, or the output of a previous flow step.Note: If this record is deleted, the flow stops waiting and continues running.
- Table
- Data type: Table Name
The table associated with the record to monitor. This read-only value is set to the table associated with the record you selected. Confirm that the system supports Wait for Condition for your selected table. For a list of unsupported tables, see the Unsupported tables section.
- Conditions
- Data type: Conditions
The record values necessary to resume running the flow. For example, if the condition is [State] [is] [Closed], the flow pauses until the condition is met. Once met, the flow moves on to the next flow step. Only select conditions that apply to field values in the table to which the record belongs. See Condition evaluation for more information about creating valid conditions.Note: For conditions that depend on a specific duration, consider using Wait for a duration flow logic instead.
- Enable Timeout
- Data type: True/False
Option to limit the amount of time that the flow waits for the action to be completed before continuing.Note: Use the Enable timeout option to prevent this action from continuing to run. If the condition to continue is never met, a timeout value specifies when the system skips the Wait for Condition action and goes to the next item in the flow. You must set a Duration value to enable a timeout. You can also select a Schedule if you want to compute the duration end date based on a specific work schedule.
- Duration
- Data type: Duration
Amount of time that the flow waits before continuing when the Enable timeout option is selected. Enter the time to wait in hours, minutes, and seconds. If you leave this field empty, the flow does not wait.
- Schedule
- Data type: Choice
Schedule used to compute the timeout duration when the Enable timeout option is selected. For example, waiting for 10 hours as part of an 8-5 weekdays schedule causes the flow to wait for one or more business days. If you leave this field empty, the timeout runs without a schedule.
Outputs
These outputs appear in the Data panel. You can use them as inputs elsewhere in your flow.
- State
- Data type: Choice
The completion status of the action as a numeric value.
- 0 (success)
- 1 (error)
Condition evaluation
- Each condition evaluates a field from the table to which the record belongs.Note: Don't create conditions that dot-walk to another table or depend upon catalog item variables from a related record.
- Each condition specifies a field value change rather than a relative time period.Note: For conditions that depend on a specific duration, consider using Wait for a duration flow logic instead.
In this example, the wait condition is valid because the State field belongs to the Incident table and the condition is a field value change to Closed.
In this example, the wait condition is invalid because it is a time relative to the Created date. Actions that have a condition that relies on a time interval will not be met, so the action is never performed.
Example: Wait for incident state closed
In this example, a subflow provides an incident record as an input to the Wait For Condition action. The condition is valid because it uses a field value from the Incident table.
General guidelines
Follow these general guidelines when creating flows that wait for a condition.
- Add trigger conditions instead of wait conditions to start flows
- If you only want a flow to run when certain record conditions are met, create a flow with a record trigger instead of starting and pausing a flow. A waiting flow consumes more system resources than a flow trigger.
- Cancel flows whose resume conditions can never occur
- Prevent your flows from waiting indefinitely by specifying flow stop conditions with End Flow flow logic. To free up system resources, you can also cancel any flow whose resume conditions can never be met. For example, cancel flows waiting for incident record updates where the related incident is closed.
- Provide at least one condition to resume a flow
- The Wait For Condition action requires at least one condition to resume running a flow. If you want to pause a flow for a specific amount of time, use the Wait for a duration of time flow logic instead.
- Restrict wait conditions to fields present on the current table
- The Wait For Condition action can only monitor changes to the fields of the table to which the record belongs. Don't create conditions that dot-walk to fields in other tables. The action can't detect changes to fields in related records or catalog variables. For example, if an action waits for changes to an Incident record, then it cannot detect changes to a related record such as a catalog item or change task record. Instead of building wait conditions that dot-walk to another record, look up the related record whose value you want to monitor and use that record as the input of your Wait for Condition action. Avoid building wait conditions that rely on catalog variables.
- Use a conditions data pill to specify dynamic conditions
- To enable flow designers to dynamically apply conditions, define an input of type Conditions and drag-and-drop the input data pill into the Conditions field.
Unsupported tables
The system does not support Wait for Condition for the following tables.