# Triggers > Triggers provide a uniform mechanism for subscribing to events from the Connector platforms. It gives you the flexibility to automatically start automations in Orchestrator. Triggers provide a uniform mechanism for subscribing to events from the Connector platforms. It gives you the flexibility to automatically start automations in Orchestrator. ## Triggers in Orchestrator :::important Starting 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](https://docs.uipath.com/integration-service/automation-cloud/latest/release-notes/2025) 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: * 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 ](https://docs.uipath.com/orchestrator/automation-cloud/latest/user-guide/configuring-access-for-accounts) in the Orchestrator user guide. ### How triggers work Polling-based triggers such as **Record Created** or **Incident Created** are available for multiple UiPath connectors. This type of trigger detects new records by using a polling mechanism against the target application's public APIs. The triggers operate as follows: 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 You create disconnected event triggers directly from Orchestrator. For details, refer to the [Event triggers](https://docs.uipath.com/orchestrator/automation-cloud/latest/user-guide/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 triggers associated with 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. Select Orchestrator from the product launcher. 2. Select a folder, and then navigate to the **Connections** tab. 2. On the right side of a connection, select **More actions** > **View/Edit** to open the edit connection page. 3. 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 :::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 ![docs image](https://dev-assets.cms.uipath.com/assets/images/integration-service/integration-service-docs-image-367696-45418e9f.svg) 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 identifier for the object involved in the event. :::note This applies only to disconnected triggers. For connected triggers, you should have the entire object already available when you design your process. ::: 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](https://docs.uipath.com/studio/standalone/latest/user-guide/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: ![docs image](https://dev-assets.cms.uipath.com/assets/images/integration-service/integration-service-docs-image-48943-8ba4cb26.webp) ### 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](https://docs.uipath.com/integration-service/automation-cloud/latest/user-guide/uipath-microsoft-onedrive-events#microsoft-onedrive-%26amp%3B-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](https://docs.uipath.com/integration-service/automation-cloud/latest/user-guide/troubleshooting-limitations#trigger-limitations). ## Frequently asked questions ### If a connection breaks, what happens to the triggers associated with that connection ? If a connection becomes disconnected, the associated triggers will temporarily stop running. Once the connection is reconnected successfully, the triggers will automatically resume execution. As an additional step, make sure the trigger is **not in a disabled state**. ### For disconnected triggers, how can I associate the trigger output with my process? See the [Event arguments](https://docs.uipath.com/integration-service/automation-cloud/latest/user-guide/triggers#event-arguments) section for details on how to retrieve data regarding the connector and the event that triggers a process. Using the **UiPathEventObjectId** argument, you can add a **Get Record** or **HTTP activity** call in your process to fetch the corresponding record data. :::note This applies only to disconnected triggers. For connected triggers, you should have the entire object already available when you design your process. ::: ### How can I change the polling interval for my trigger? You can modify the polling interval directly from the trigger configuration. Refer to this guide for detailed steps: [Updating the Polling Interval](https://docs.uipath.com/integration-service/automation-cloud/latest/user-guide/triggers#updating-the-polling-interval). ### Can I filter which records trigger my automation? Yes. You can add **Data filters** (for connectors that support it) to control which records ultimately kick off your process. :::note Filters are applied after the records are fetched by Integration Service. ::: For example: * Create a filter in Studio Web: ![trigger-filter-Studio](https://dev-assets.cms.uipath.com/assets/images/integration-service/trigger-filter-studio-4a05af7a.webp) * Create a filter in Orchestrator: ![trigger-filter-Orchestrator](https://dev-assets.cms.uipath.com/assets/images/integration-service/trigger-filter-orchestrator-a27424f5.webp) ### Why is my trigger not firing immediately? Trigger execution timing can vary depending on the **trigger type**, **data volume**, and **robot availability**. For polling-based triggers: * 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. ::: For webhook-based triggers (e.g., HTTP Webhook): * 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. ### How do I troubleshoot a trigger that's not firing? * 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. ### When does a trigger pick up records for the first time? The **first run** of a trigger begins from the **time the trigger is created**. Records created **before the trigger was created** are not picked up and all records created/updated **after the trigger creation timestamp** are eligible for processing according to the trigger's filters. ### During debug mode, when does the trigger pick up records for the first time? During debug mode, the Start Event trigger (the trigger that initiates a process) considers events from the **past 1 hour** relative to the time of configuration.