Déclencheurs (Triggers)

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

Déclencheurs dans Orchestrator

Important :

À partir de fin avril 2025, vous pouvez créer de nouveaux déclencheurs Integration Service uniquement dans Orchestrator. Les déclencheurs créés dans Orchestrator ne seront pas répertoriés dans l’onglet Triggers de l’Integration Service. Les déclencheurs du Integration Service existants continueront de s'exécuter et resteront visibles dans l'onglet Triggers du Integration Service jusqu'au 31 juillet 2025 (cette date est soumise à des extensions possibles). Après cette date, les déclencheurs Integration Service existants seront migrés vers Orchestrator et l'onglet Triggers du Integration Service sera supprimé. Il est prévu que cette modification soit d'abord disponible pour les utilisateurs Community, puis progressivement pour les utilisateurs Enterprise, en fonction des régions des organisations et des locataires. Suivez le Guide des notes de publication d'Integration Service pour savoir quand le changement est annoncé pour la première fois.

Principaux avantages des déclencheurs dans Orchestrator

Le déplacement des déclencheurs Integration Service vers Orchestrator constitue un grand changement, mais comporte de nombreux avantages. Voici les principales raisons pour lesquelles cette mise à jour est à l’origine :

1. Mappage compte-machine: Orchestrator permet de contrôler au niveau de la machine les processus déclenchés par Integration Service.
2. Contrôle de l'exécution du processus spécifique au bot: Orchestrator vous permet de spécifier quel robot doit exécuter un processus dans un dossier où plusieurs bots sont affectés. Cela permet de contrôler avec précision le bot qui exécute un processus déclenché, élimine le besoin de solutions de contournement telles que les dossiers à bot unique et améliore l’évolutivité en permettant à plusieurs bots sans perdre le contrôle de l’exécution.
3. Arguments d'entrée et allocation dynamique des processus: Orchestrator active les arguments d'entrée dynamiques et vous permet de définir le nombre maximum d'instances de processus actives. Cela réduit la duplication des processus en permettant des arguments dynamiques, optimise l'utilisation des ressources en limitant les processus actifs et améliore l'efficacité des processus qui gèrent les requêtes de manière séquentielle.
4. Gestion améliorée des processus de longue durée: les déclencheurs créés dans Orchestrator prennent en charge les options « Arrêter après » et « Arrêter l'arrêt après », permettant l'arrêt automatique des processus après une durée ou une condition spécifiée. Cela permet d’éviter une surutilisation des ressources en mettant fin aux processus de longue durée et garantit une exécution rapide en arrêtant les workflows qui ne répondent pas.
5. Capacités de modification: Orchestrator vous permet de modifier les déclencheurs existants.
6. Expérience de déclencheur unifiée: créez et gérez tous les types de déclencheurs à partir d'un seul emplacement.
7. Vue du déclencheur unique: le déplacement de la création du déclencheur vers Orchestrator garantit que tous les déclencheurs basés sur Integration Service conservent une vue unique. Vous pouvez désormais créer un déclencheur basé sur Integration Service de deux manières : à partir d'Integration Service, en créant un déclencheur pour un connecteur spécifique, et à partir de Studio, en utilisant une activité de déclencheur pour démarrer une automatisation. Les informations de configuration affichées pour les deux déclencheurs peuvent différer légèrement, même s'ils capturent le même événement.

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.

Création de déclencheurs

Vous créez des déclencheurs d'événements déconnectés directement à partir d'Orchestrator. Pour de plus amples informations, consultez la section Déclencheurs d'événement du guide de l'utilisateur d'Orchestrator.

Orchestrator fournit une gestion directe de ces déclencheurs. Dans Integration Service, votre seule option de modification de déclencheur consiste à ajuster l'intervalle d'interrogation, qui est défini au niveau de la connexion.

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. 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. Sélectionnez Update (Mettre à jour).

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

Important :

La table Historique des tentatives est disponible exclusivement pour les déclencheurs créés dans Integration Service et répertoriés dans l’onglet Déclencheurs . L'historique des tentatives n'est pas disponible pour les déclencheurs créés dans Orchestrator.

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.

Les déclencheurs créés directement dans Orchestrator peuvent être gérés depuis Orchestrator.

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 et vous pouvez 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.

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.

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.

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.