Auslöser

Trigger bieten einen einheitlichen Mechanismus zum Abonnieren von Ereignissen von den Connector-Plattformen. Sie gibt Ihnen die Flexibilität, Automatisierungen oder Prozesse im Orchestrator automatisch zu starten.

Überblick

Es gibt zwei Arten von Ereignistriggern, die auf Integration Service-Verbindungen basieren:

• Verbunden – Erstellt mit Triggeraktivitäten in Studio, verwendet in einem Prozess.
• Getrennt – Erstellt im Orchestrator oder Integration Service, wird verwendet, um eine Automatisierung zu starten.

Hinweis:

Trigger hängen von Verbindungen ab. Durch das Löschen einer Verbindung werden auch alle zugehörigen Trigger gelöscht.

Voraussetzungen

Bevor Sie Trigger konfigurieren können, stellen Sie sicher, dass die folgenden Bedingungen erfüllt sind:

• Integration Service is enabled and provisioned for your tenant.
• You have already set up an Unattended or Non-production Robot in your Orchestrator instance.
• Sie verwenden moderne Ordner (Prozesse innerhalb klassischer Ordner sind beim Definieren von Triggern nicht sichtbar).
• 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}

   Hinweis:

   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.

Aktualisieren des Abrufintervalls

Connectors unterstützen Ereignisse durch einen Abrufmechanismus.

Wenn Sie einen Ereignistrigger für eine Verbindung einrichten, wird das Abrufintervall standardmäßig auf fünf Minuten festgelegt.

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.

Das Abrufen wird für die Verbindung im ausgewählten Intervall ausgeführt. Sobald Daten abgerufen wurden, werden alle aktiven Trigger für diese Verbindung auf das Dataset angewendet. Wenn eine Abfrage ausgeführt wird, während Sie das Intervall ändern, wartet der Dienst auf den Abschluss der vorhandenen Abfrage und startet dann eine andere.

So aktualisieren Sie das Abrufintervall:

1. Wechseln Sie im Integration Service zur Registerkarte Verbindungen .
2. Wählen Sie eine bestimmte Verbindung aus, um die Seite mit den Verbindungsdetails zu öffnen. Das Abrufintervall wird nur für Verbindungen mit hinzugefügten Triggern angezeigt.
3. Wählen Sie das Zeitintervall aus, um das Fenster Abrufintervall aktualisieren zu öffnen.
4. Sie können eine der verfügbaren Optionen auswählen oder ein benutzerdefiniertes Intervall in Minuten oder Stunden festlegen. Das Abrufintervall muss mehr als eine Minute und darf höchstens 24 Stunden oder 1440 Minuten betragen.
5. Wählen Sie Aktualisieren und überprüfen.

Anzeigen des Verlaufs der Trigger-Ausführung

So zeigen Sie den Verlauf der Trigger-Ausführung an:

1. Wählen Sie in Integration Service die Registerkarte Trigger aus.
2. Wählen Sie für jeden aufgeführten Trigger die Option Trigger mit anzeigen Menü „Weitere Aktionen“:

Die Verlaufstabelle der Versuche zeigt:

• Die Ereigniszeit – Wenn das Ereignis erfasst wurde
• Die Anzahl der Versuche
• Der Triggerstatus – ob der Prozess erfolgreich gestartet wurde oder nicht.

Hinweis:

Der Status Erfolgreich zeigt nur an, dass der Auftrag erfolgreich gestartet wurde. Es spiegelt nicht wider, ob der Auftrag erfolgreich bis zum Ende ausgeführt wurde oder nicht. Falls ein Auftrag nicht gestartet werden kann, wird sein Status als Fehlgeschlagen angezeigt. Zeigen Sie mit dem Mauszeiger auf den Status Fehlgeschlagen , um die Fehlermeldung anzuzeigen.

Um zu überprüfen, ob ein Auftrag erfolgreich ausgeführt wurde, wählen Sie die Taste Auftragsprotokolle anzeigen . Diese Aktion leitet Sie zum Orchestrator um, wo Sie alle erforderlichen Informationen zur Auftragsausführung sehen können.

Verwalten von Triggern

Die folgenden Aktionen sind für Trigger verfügbar, die im Integration Service erstellt wurden.

Umbenennen eines Triggers

Führen Sie die folgenden Schritte aus, um einen Trigger umzubenennen:

1. Access the Triggers tab.
2. Zeigen Sie mit dem Mauszeiger auf den Namen des Triggers, den Sie ändern möchten. Die Schaltfläche Bearbeiten wird angezeigt.

Alternativ können Sie Ihren Trigger aus der Liste auswählen, um auf die detaillierte Ansicht zuzugreifen. Die Schaltfläche Bearbeiten befindet sich rechts neben Ihrem Triggernamen. 3. Wählen Sie die Schaltfläche Bearbeiten aus. Sie können einen neuen Namen für Ihren Trigger wählen

Löschen eines Triggers

Wechseln Sie im Fenster Integration Service zur Registerkarte Trigger . Wählen Sie die Schaltfläche Weitere Aktionen aus, die Ihrem Trigger entspricht, und wählen Sie Löschen.

Aktivieren oder Deaktivieren eines Triggers

Um einen Trigger zu aktivieren oder zu deaktivieren, müssen Sie ihn zuerst auswählen, um seine Details anzuzeigen. Wählen Sie dann den Schalter aus, der sich auf der oberen linken Seite des Fensters befindet.

Ereignisargumente

Getrennte Trigger ermöglichen es Ihnen, Daten in Bezug auf den Connector und das Ereignis abzurufen, das einen Prozess auslöst.

Wenn Sie den tatsächlichen Connector, das Ereignis, den Datensatztyp oder den Datensatz wissen möchten, der den Prozess in Ihrem Workflow ausgelöst hat, definieren Sie die folgenden Eingabeargumente des Typs String in Ihrem Prozess. Integration Service füllt sie automatisch auf, wenn er den Auftrag startet:

• UiPathEventConnector – Bestimmt, welcher Connector die Automatisierung gestartet hat.
• UiPathEvent – Bestimmt den Typ des aufgetretenen Ereignisses.
• UiPathEventObjectType – Definiert den spezifischen Datensatztyp, der sich aus dem Ereignis ergibt.
• UiPathEventObjectId - Provides the unique identifier for the object involved in the event.

Hinweis:

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

Sie können diesen Argumenten keinen Wert zuweisen. Sie werden zum Zeitpunkt der Triggerausführung automatisch aufgefüllt und Sie können sie im Argumentbereich in Studio nicht anzeigen oder bearbeiten. Weitere Informationen zur Funktionsweise und Verwaltung von Argumenten finden Sie in der Studio-Dokumentation: Verwalten von Argumenten.

Um einen Datensatz abzurufen, der einen Trigger bei einer Auftragsausführung hat, verwenden Sie das Eingabeargument UiPathEventObjectId , um den Datensatz aus dem Quellsystem abzurufen.

Hier ist ein Beispiel dafür, wie Integration Service die Eingabeargumentwerte an Orchestrator-Protokolle übergibt:

Triggerspezifische Ausgaben

Verbundene Trigger haben objektspezifische Ausgaben. Beispielsweise gibt der Microsoft OneDrive & SharePoint E-Mail erhalten Trigger ein Objekt vom Typ Office365Message mit Eigenschaften wie AttachmentsNamesList, FromAddress, InternetMessageId, SentDateTime usw. aus. Weitere Informationen finden Sie unter Microsoft OneDrive & SharePoint-Ereignisse.

Verwenden Sie den Ausdrucks-Editor in Studio, um alle verfügbaren Eigenschaften für ein beliebiges Trigger-Ausgabeobjekt anzuzeigen.

Häufig gestellte Fragen

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.

Hinweis:

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.

Hinweis:

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

Zum Beispiel:

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

  Hinweis:

  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.

Einschränkungen

Trigger-Einschränkungen werden im Abschnitt zur Fehlerbehebung dieses Handbuchs dokumentiert. Siehe Trigger-Einschränkungen.