Déclencheurs (Triggers)

Les déclencheurs fournissent un mécanisme uniforme d'abonnement aux événements à partir des plates-formes du connecteur. Il vous donne la possibilité de démarrer automatiquement des automatisations ou des processus dans Orchestrator.

Vue d'ensemble (Overview)

Il existe deux types de déclencheurs d'événement basés sur les connexions Integration Service :

• Connecté : créé avec des activités de déclencheur dans Studio, utilisé à l'intérieur d'un processus.
• Déconnecté : créé dans Orchestrator ou dans Integration Service, utilisé pour démarrer une automatisation.

Remarque :

Les déclencheurs dépendent des connexions. La suppression d'une connexion supprime également tous les déclencheurs associés.

Prérequis

Avant de pouvoir configurer des déclencheurs, assurez-vous que les conditions suivantes sont remplies :

• Integration Service is enabled and provisioned for your tenant.
• You have already set up an Unattended or Non-production Robot in your Orchestrator instance.
• Vous utilisez des dossiers modernes (les processus à l'intérieur des dossiers classiques ne sont pas visibles lors de la définition des déclencheurs).
• 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

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}

   Remarque :

   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.

Mise à jour de l'intervalle d'interrogation

Les connecteurs prennent en charge les événements via un mécanisme d'interrogation.

Lorsque vous configurez un déclencheur d'événement sur une connexion, l'intervalle d'interrogation est défini par défaut sur cinq 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.

L’interrogation s’exécute sur la connexion à l’intervalle sélectionné. Une fois les données récupérées, tous les déclencheurs actifs pour cette connexion sont appliqués à l'ensemble de données. Si une interrogation est en cours d'exécution lorsque vous modifiez l'intervalle, le service attend la fin de l'interrogation existante, puis en démarre une autre.

Pour mettre à jour l'intervalle d'interrogation :

1. Dans Integration Service, accédez à l'onglet Connexions .
2. Sélectionnez une connexion spécifique pour ouvrir la page des détails de connexion. L'intervalle d'interrogation s'affiche uniquement pour les connexions avec des déclencheurs ajoutés.
3. Sélectionnez l'intervalle de temps pour ouvrir la fenêtre Mettre à jour l'intervalle d'interrogation .
4. Vous pouvez choisir l'une des options disponibles ou configurer un intervalle personnalisé, en minutes ou en heures. L'intervalle d'interrogation doit être supérieur à une minute et ne doit pas dépasser 24 heures ou 1 440 minutes.
5. Sélectionnez Mettre à jour et vérifier.

Afficher l'historique des exécutions de déclencheur

Pour afficher l'historique des exécutions de déclencheur :

1. Dans Integration Service, sélectionnez l'onglet Déclencheurs .
2. Pour tout déclencheur répertorié, sélectionnez Afficher le déclencheur à l’aide du Menu Autres actions :

La table Historique des tentatives indique :

• L'heure de l'événement : le moment où l'événement a été capturé
• Le nombre de tentatives
• L'état du déclencheur : indique si le processus a été lancé ou non.

Remarque :

L'état Réussi indique uniquement que la tâche a été lancée avec succès. Il n'indique pas si la tâche a été correctement exécutée jusqu'à la fin ou non. Si une tâche ne démarre pas, son état apparaîtra comme Échec. Pointez avec le curseur de la souris sur l’état Échec pour afficher le message d’erreur.

Pour vérifier si une tâche a été exécutée correctement, sélectionnez le bouton View job logs . Cette action vous redirige vers Orchestrator, où vous pouvez voir toutes les informations nécessaires sur l'exécution de la tâche.

Gestion des déclencheurs

Les actions suivantes sont disponibles pour les déclencheurs créés dans Integration Service.

Renommer un déclencheur

Pour renommer un déclencheur, procédez comme suit :

1. Access the Triggers tab.
2. Pointez avec le curseur de la souris sur le nom du déclencheur que vous souhaitez modifier. Le bouton Modifier s'affiche.

Vous pouvez également sélectionner votre déclencheur dans la liste pour accéder à la vue détaillée. Le bouton Modifier se trouve à droite du nom de votre déclencheur. 3. Sélectionnez le bouton Modifier pour choisir un nouveau nom pour votre déclencheur

Suppression d'un déclencheur

Accédez à l'onglet Déclencheurs dans la fenêtre Integration Service . Sélectionnez le bouton Autres actions correspondant à votre déclencheur et sélectionnez Supprimer.

Activation ou désactivation d'un déclencheur

Pour activer ou désactiver un déclencheur, vous devez d'abord le sélectionner pour afficher ses détails. Sélectionnez ensuite le commutateur situé dans le coin supérieur gauche de la fenêtre.

Arguments d'événement

Les déclencheurs déconnectés vous permettent de récupérer des données concernant le connecteur et l'événement qui déclenche un processus.

Si vous souhaitez connaître le connecteur réel, l'événement, le type d'enregistrement ou l'enregistrement qui a déclenché le processus dans votre workflow, définissez les arguments d'entrée suivants de type String dans votre processus. Integration Service les remplit automatiquement lorsqu'il démarre la tâche :

• UiPathEventConnector : Détermine quel connecteur a démarré l'automatisation.
• UiPathEvent : détermine le type d'événement qui s'est produit.
• UiPathEventObjectType : définit le type d'enregistrement spécifique résultant de l'événement.
• UiPathEventObjectId - Provides the unique identifier for the object involved in the event.

Remarque :

This applies only to disconnected triggers. For connected triggers, you should have the entire object already available when you design your process.

Vous ne pouvez affecter aucune valeur à ces arguments. Ils sont remplis automatiquement au moment de l'exécution du déclencheur et vous ne pouvez pas les afficher ou les modifier à partir du panneau Arguments dans Studio. En savoir plus sur le fonctionnement des Arguments et leur gestion dans la documentation de Studio : Gestion des arguments.

Pour récupérer et utiliser un enregistrement disposant d'un déclencheur sur une exécution de tâche, utilisez l'argument d'entrée UiPathEventObjectId pour récupérer l'enregistrement du système source.

Voici un exemple de la façon dont Integration Service transmet les valeurs d'argument d'entrée dans les journaux Orchestrator :

Sorties spécifiques au déclencheur

Les déclencheurs connectés ont des sorties spécifiques aux objets. Par exemple, le déclencheur Microsoft OneDrive & SharePoint E-mail reçu génère un objet de type Office365Message, avec des propriétés telles que AttachmentsNamesList, FromAddress, InternetMessageId, SentDateTime etc. Pour plus de détails, consultez la section Événements Microsoft OneDrive & SharePoint.

Utilisez l' éditeur d'expressions dans Studio pour afficher toutes les propriétés disponibles pour tout objet de sortie de déclencheur.

Questions fréquemment posées

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 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.

Remarque :

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.

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.

Remarque :

Filters are applied after the records are fetched by Integration Service.

Par exemple :

• Create a filter in Studio Web:

  

• Create a filter in Orchestrator:

  

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.

  Remarque :

  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.

Limitations

Les limitations de déclencheur sont documentées dans la section Résolution des problèmes de ce guide. Voir Limitations des déclencheurs.