Triggers

Triggers provide a uniform mechanism for subscribing to events from the Connector platforms. It gives you the flexibility to automatically start automations or processes in Orchestrator.

Triggers in Orchestrator

Important:

Starting in late April 2025, you can create new Integration Service triggers only in Orchestrator.

Triggers created in Orchestrator will not be listed on the Integration Service Triggers tab. Existing Integration Service triggers will continue to run and remain visible on the Integration Service Triggers tab until July 31, 2025 (this date is subject to possible extensions). After this date, existing Integration Service triggers will be migrated to Orchestrator, and the Triggers tab in Integration Service will be removed.

This change is scheduled to become available to Community users first, then to Enterprise users progressively, depending on organization and tenant regions. Follow the Integration Service release notes guide to learn when the change is first announced.

Key benefits of triggers in Orchestrator

Moving Integration Service triggers to Orchestrator is a big change, but it comes with many benefits. Here are the main reasons driving this update:

1. Account-machine mapping: Orchestrator enables machine-level control over Integration Service-triggered processes.
2. Bot-specific process execution control: Orchestrator allows you to specify which robot should execute a process in a folder where multiple bots are allocated. This provides precise control over which bot executes a triggered process, eliminates the need for workarounds like single-bot folders, and enhances scalability by allowing multiple bots without losing execution control.
3. Input arguments and dynamic process allocation: Orchestrator enables dynamic input arguments and allows you to define the maximum number of active process instances. This reduces process duplication by allowing dynamic arguments, optimizes resource usage by limiting active processes, and improves efficiency for processes that manage requests sequentially.
4. Improved management of long-running processes: Triggers created in Orchestrator support the "Stop after" and "Kill after" options, allowing the automatic termination of processes after a specified duration or condition. This prevents resource overuse by terminating long-running processes and ensures timely execution by stopping unresponsive workflows.
5. Editing capabilities: Orchestrator enables you to edit existing triggers.
6. Unified trigger experience: Create and manage all types of triggers from one location.
7. Single trigger view: Moving trigger creation to Orchestrator ensures all Integration Service-based triggers retain a single view. You can now create an Integration Service-based trigger in two ways: from Integration Service, by creating a trigger for a specific connector, and from Studio, by using a trigger activity to start an automation. The configuration information displayed for the two triggers can differ slightly, even though they capture the same event.

Overview

There are two types of event triggers based on Integration Service connections:

• Connected – Created with trigger activities in Studio, used inside a process.
• Disconnected – Created in Orchestrator or Integration Service, used to start any automation.

Note: Triggers depend on connections. Deleting a connection also deletes all associated triggers.

Prerequisites

Before you can configure triggers, make sure the following conditions are met:

• The Integration Service is enabled and provisioned for your tenant.
• You have already setup an Unattended or Non-production Robot in your Orchestrator instance.
• You are using modern folders (processes inside of classical folders are not visible when defining triggers).

Creating triggers

You create disconnected event triggers directly from Orchestrator. For details, refer to the Event triggers section in the Orchestrator user guide.

Orchestrator provides direct management of these triggers. In Integration Service, your only option for trigger modification is adjusting the polling interval, which is set at connection level.

Updating the polling interval

Connectors support events through a polling mechanism.

When you set up an event trigger on a connection, the polling interval is set by default to five minutes.

The polling interval is set at connection level. This means you can have only one polling interval per connection, even though you create several triggers per connection. Changing the polling interval affects all the associated triggers on a connection.

Polling runs on the connection at the selected interval. Once data has been retrieved, all active triggers for that connection are applied to the data set. If a poll is running when you change the interval, the service waits for the existing poll to finish, then starts another one.

To update the polling interval:

1. In Integration Service, go to the Connections tab.
2. Select a specific connection to open the connection details page.

   The polling interval is displayed only for connections with added triggers.

3. Select the time interval to open the Update polling interval window.

4. You can choose one of the available options or set up a custom interval, in minutes or hours. The polling interval must be more than one minute and not longer than 24 hours or 1440 minutes.

5. Select Update and Check.

Viewing the trigger run history

Important: The Attempts' history table is available exclusively for triggers created in Integration Service and listed in the Triggers tab. Attempts' history is not available for triggers created in Orchestrator.

To view the trigger run history:

1. In Integration Service, select the Triggers tab.
2. For any listed trigger, select View trigger using the More actions menu:

The Attempts' history table shows:

• The event time – when the event was captured
• The number of attempts
• The trigger state – whether the process was successfully launched or not.

Note: The Successful state only indicates that the job was successfully launched. It does not reflect whether the job was successfully executed to the end or not. In case a job fails to start, its State will appear as Failed. Hover with the mouse cursor over the Failed state to view the error message.

To check if a job was successfully executed, select the View job logs button. This action redirects you to Orchestrator, where you can see all the necessary information on job execution.

Managing triggers

The following actions are available for triggers created in Integration Service. Triggers created directly in Orchestrator can be managed from Orchestrator.

Renaming a trigger

To rename a trigger, take the following steps:

1. Access the Triggers tab.
2. Hover with the mouse cursor over the name of the trigger you wish to modify. The Edit button is displayed.
   Alternatively, you can select your trigger from the list to access the detailed view. The Edit button is located on the right side of your trigger name.
3. Select the Edit button and you can choose a new name for your trigger

Deleting a trigger

Go to the Triggers tab in the Integration Service window. Select the More Actions button corresponding to your trigger and select Delete.

Activating or deactivating a trigger

To activate or deactivate a trigger, you first have to select it to view its details. Then select the switch located in the upper-left side of the window.

Event arguments

Disconnected triggers allow you to retrieve data regarding the connector and event that triggers a process.

If you want to know the actual connector, event, record type, or record that triggered the process in your workflow, define the following input arguments of type String in your process. Integration Service populates them automatically when it starts the job:

• UiPathEventConnector - Determines which connector started the automation.
• UiPathEvent - Determines the type of event that occurred.
• UiPathEventObjectType - Defines the specific record type resulting from the event.
• UiPathEventObjectId - Provides the unique identified for the object involved in the event.

You cannot assign any value to these arguments. They are populated automatically at trigger execution time, and you are unable to view or edit them from the Arguments panel in Studio. Find out more about how Arguments work and how to manage them from the Studio documentation: Managing Arguments.

To retrieve and work with a record that has a trigger on a job run, use the UiPathEventObjectId input argument to retrieve the record from the source system.

Here is an example of how Integration Service passes the input argument values into Orchestrator logs:

Trigger-specific outputs

Connected triggers have object-specific outputs. For example, the Microsoft OneDrive & SharePoint Email Received trigger outputs an object of type Office365Message, with properties such as AttachmentsNamesList, FromAddress, InternetMessageId, SentDateTime etc. For details, refer to Microsoft OneDrive & SharePoint events.

Use the Expression Editor in Studio to view all available properties for any trigger output object.

Limitations

Trigger limitations are documented in the Troubleshooting section of this guide. See Trigger limitations.