Integration Service user guide

Triggers

Triggers in Orchestrator​

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​

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

Prerequisites​

• Integration Service is enabled and provisioned for your tenant.
• You have already set up 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).
• Users who work with triggers have the necessary permissions in Orchestrator. To create a trigger, a user must have the Triggers - Create permission in the target folder. For more information on permissions, see Configuring access for accounts in the Orchestrator user guide.

How triggers work​

1. Polling interval - Integration Service polls the target system at a set interval (by default every five minutes). The polling interval is set at connection level, therefore changing the polling interval affects all the triggers associated with that connection.

2. API-based detection - During each polling cycle, Integration Service queries the relevant object/table using the vendor's standard REST APIs.

3. Incremental record identification - New records are identified using API query parameters, most commonly based on:

   • Record creation timestamp (for example, sys_created_on)
   • In some scenarios, modification timestamps

   Integration Service stores the most recent creation timestamp (or equivalent marker) from the last successful polling cycle. On the next poll, the query resumes from that stored value, ensuring continuity and preventing duplicate processing.

   For example, a query to poll for new incidents in ServiceNow could look as follows: GET https://{instance}.service-now.com/api/now/v1/table/incident?sysparm_query=sys_created_on>={last_max_created_date}

   Note:

   Additional parameters such as pagination, limits, offsets, or field expansion may be included to support filtering and data shaping. These do not change the core polling logic.

Creating triggers​

Updating the polling interval​

1. Select Orchestrator from the product launcher.
2. Select a folder, and then navigate to the Connections tab.
3. On the right side of a connection, select More actions > View/Edit to open the edit connection page.
4. Under Check for events every:, select the time 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.

Viewing 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 event time – when the event was captured
• The number of attempts
• The trigger state – whether the process was successfully launched or not.

Managing triggers​

Renaming a trigger​

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​

Activating or deactivating a trigger​

Event arguments​

• 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 identifier for the object involved in the event.

Trigger-specific outputs​

Limitations​

Frequently asked questions​

• Create a filter in Studio Web:

  

• Create a filter in Orchestrator:

  

• The trigger fetches new or updated records based on the polling interval configured in Integration Service.

• Depending on the volume of data retrieved, Integration Service applies any defined filters or trigger conditions before passing qualifying events to Orchestrator.

• This processing can introduce minor latency, especially when handling large datasets or complex filters.

• After the events are handed over to Orchestrator, the automation starts only if an unattended robot is available at that moment.

• If the polling interval is set too long, a large volume of data may be retrieved at once, potentially slowing down your process. In such cases, consider reducing the interval to improve performance.

  Note:

  If your trigger appears delayed, check your polling interval, review filters for efficiency, and ensure that an unattended robot is available to execute the job.

• Webhook triggers are designed to fire almost instantly, as events are sent directly by the external application to Integration Service.
• Since webhooks typically handle one record per transaction, latency is minimal.
• However, if trigger filters or processing logic are applied before the event is handed off to Orchestrator, you may still observe a small delay.

• Verify that the associated connection is active.
• Check that the trigger is enabled.
• Verify whether your connection requires a specific scope or role to access the target API endpoint that is being polled.
• Confirm that the filter matches expected data.
• For webhook triggers, confirm the webhook registration is valid on the external application.