Workflow Studio flow trigger types
-
- UpdatedAug 1, 2024
- 11 minutes to read
- Xanadu
- Create Workflows
Each trigger type defines when a flow starts and the starting data available to it. There are triggers for record operations, dates, and application operations.
Record triggers
Use record triggers to start a flow when a record is created or updated.
Trigger | Description |
---|---|
Created | Starts a flow when a record is created in a specific table. |
Updated | Starts a flow when a record is updated in a specific table. Requires
selecting when to run the flow.
|
Created or Updated | Starts a flow when a record is either created or updated in a specific table.
Requires selecting when to run the flow.
|
REST triggers
Use REST triggers to start a flow after a specific REST API request.
Trigger | Description |
---|---|
REST API - Asynchronous | Start a flow from an inbound API call or webhook from an external system. Configure the trigger start conditions without having to write or maintain custom code. For more information, see REST API trigger. |
Scheduled triggers
Application triggers
Use application triggers to start a flow when application-specific conditions are met.
Inbound email triggers
Start a flow when your instance receives an email.
Inbound email flows take priority over inbound email actions. If you create flows with inbound email triggers, emails are first processed by the inbound email triggers before they are processed by inbound email actions.
With inbound email actions, you don't have full control over email attachment handling or assigning the target record of an email. When you create a flow with an inbound email trigger, you can perform these actions with the Move Email Attachments to Record action and the Associate Record to Email action. For greater control over email attachments, you can also use the Look up email attachments action to access a specific attachment as a data pill.
Although you can process an inbound email with multiple inbound email actions, you can't process an inbound email with multiple flows by default. Additional configuration is required. For information on how to stop processing in inbound email actions, see Specifying the inbound email processing order.
For more information on running multiple flows on an inbound email, see Allow multiple triggers to process an inbound email.
The following diagram shows how inbound emails are processed by inbound email triggers. After the email has been classified as a reply, forward, or new email, the system tries to match the email to an active inbound email trigger. If the email meets the conditions of an inbound email trigger, the flow runs. If the flow issues stop processing, the email is finished being processed. If the flow does not issue stop processing, the system evaluates the conditions of more inbound email triggers. If there are no more inbound email triggers to evaluate, the system tries to match the email with an active inbound email action instead.

Spoke triggers
Advanced options
- When to run the flow
Determine the type of session that can trigger the flow, whether to run the flow when triggered by certain users, and which tables can trigger the flow.
Table 1. Interactive session options Option Description Only Run for Non-Interactive Session Flow that is only triggered in non-interactive sessions. See Non-interactive sessions. Only Run for User Interactive Session Flow that is only triggered in interactive sessions. Run for Both Interactive and Non-Interactive Sessions Flow that is triggered in all sessions. Table 2. User options Option Description Do not run if triggered by the following users Flow that does not trigger for a selected list of users. Click the Add User icon ( ) to add users to the list.
Only run if triggered by the following users Flow that triggers only for a selected list of users. Click the Add User icon ( ) to add users to the list.
Run for any user Flow that runs for any user. Table 3. Table options Option Description Run only on current table Flow that is only triggered for the selected table. Run on current and extended tables Flow that is triggered for the selected table and any extended tables. - Where to run the flow
Determine whether to run the flow in the background or in the current session.
Option Description Run flow in background (default) Flow that runs asynchronously in the background. Use this option for flows that do not require immediate updates and to allow other system processes to run at the same time. Run flow in foreground Flow that runs synchronously in the current session. Use this option to provide immediate updates to an end user. For example, if a flow opens a task after the previous task closes, use this option to open the next task immediately after a user closes one. Note: Running a flow in foreground may block the current session thread and prevent user input until the flow finishes. Avoid running flows in the foreground when they contain actions that cannot be interrupted, such as actions that run script. Actions or flow logic that pause a flow will not block a session.
Data pills available by trigger type
Flow designers have access to data pills from the trigger.
General guidelines
Follow these general guidelines when creating record triggers.
- Determine whether your flow needs a trigger or variable input
- Flows always run when their trigger conditions are met. Triggers always provide the same data as input for flows. If you need variable input to initiate a flow instead, create a subflow.
- Add conditions to specify what record values start your flow
- Starting a flow only when needed consumes fewer system resources than starting a flow, pausing it, and waiting to resume the flow until a specific record condition applies. Instead of creating a flow that starts with a Wait for condition action, redesign the flow to include the wait condition as part of the record trigger.
- Create unique conditions for record triggers on the same table
- To prevent flows from overwriting each other, create unique conditions for each flow running on the same table. If multiple flows on the same table have the same filter conditions, there is no way to know the order in which the flows run. Using conditions also helps to optimize flow performance by returning a more precise, smaller set of records.
- Ignore records added or updated by import and update sets
- Record triggers ignore records added or updated by applying an update set or importing an XML file. These operations apply to the entire application or table rather than an individual record.
- Replace record triggers on Service Catalog tables with Service Catalog application triggers
- Flow Designer no longer displays Service Catalog tables as options for record triggers. Instead, create flows that use the Service Catalog application trigger type.
- Verify that the users who trigger a flow have access to trigger condition data
- Since flows typically run as the user who triggers them, verify that users have access to all of the data specified in the trigger conditions. Avoid creating trigger conditions to related tables that typical users don't have access to. If your flow trigger conditions require access to role-restricted data, run your flows with the role needed to access that data.