UiPath Documentation
integration-service
2.2510
true
Importante :
Este contenido se ha traducido mediante traducción automática. Los paquetes de conectores disponibles en Integration Service están traducidos con traducción automática. La localización de contenidos recién publicados puede tardar entre una y dos semanas en estar disponible.
UiPath logo, featuring letters U and I in white

Guía de usuario de Integration Service

Última actualización 17 de abr. de 2026

Desencadenadores

Los desencadenadores proporcionan un mecanismo uniforme para suscribirse a eventos desde las plataformas del conector. Le da la flexibilidad de iniciar automáticamente automatizaciones o procesos en Orchestrator.

Información general

Hay dos tipos de desencadenadores de eventos basados en las conexiones de Integration Service:

  • Conectado : creado con actividades de desencadenador en Studio, utilizado dentro de un proceso.
  • Desconectado : creado en Orchestrator o Integration Service, utilizado para iniciar cualquier automatización.
Nota:

Los desencadenadores dependen de las conexiones. Al eliminar una conexión también se eliminan todos los desencadenadores asociados.

Requisitos previos

Antes de poder configurar los desencadenadores, asegúrate de que se cumplen las siguientes condiciones:

  • Integration Service is enabled and provisioned for your tenant.
  • You have already set up an Unattended or Non-production Robot in your Orchestrator instance.
  • Está utilizando carpetas modernas (los procesos dentro de las carpetas clásicas no son visibles al definir los desencadenadores).
  • 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}

    Nota:

    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.

Actualizar el intervalo de sondeo

Los conectores admiten eventos a través de un mecanismo de sondeo.

Cuando configuras un desencadenador de eventos en una conexión, el intervalo de sondeo se establece de forma predeterminada en cinco minutos.

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.

El sondeo se ejecuta en la conexión en el intervalo seleccionado. Una vez que se han recuperado los datos, todos los desencadenadores activos para esa conexión se aplican al conjunto de datos. Si se está ejecutando una encuesta cuando cambias el intervalo, el servicio espera a que finalice la encuesta existente y luego inicia otra.

Para actualizar el intervalo de sondeo:

  1. En Integration Service, ve a la pestaña Conexiones .
  2. Selecciona una conexión específica para abrir la página de detalles de la conexión. El intervalo de sondeo se muestra solo para las conexiones con desencadenadores añadidos.
  3. Selecciona el intervalo de tiempo para abrir la ventana Actualizar intervalo de sondeo .
  4. Puedes elegir una de las opciones disponibles o configurar un intervalo personalizado, en minutos u horas. El intervalo de sondeo debe ser superior a un minuto y no superior a 24 horas o 1440 minutos.
  5. Selecciona Actualizar y comprobar.

Ver el historial de ejecución del desencadenador

Para ver el historial de ejecución del desencadenador:

  1. En Integration Service, selecciona la pestaña Desencadenadores .
  2. Para cualquier desencadenador enumerado, selecciona Ver desencadenador usando el docs image Menú Más acciones:

La tabla del historial de intentos muestra:

  • La hora del evento: cuándo se capturó el evento
  • El número de intentos
  • El estado del desencadenador: si el proceso se inició correctamente o no.
Nota:

El estado Correcto solo indica que el trabajo se ha iniciado correctamente. No refleja si el trabajo se ejecutó correctamente hasta el final o no. En caso de que un trabajo no se inicie, su estado aparecerá como Fallido. Mantén el puntero del ratón sobre el estado Fallido para ver el mensaje de error.

Para comprobar si un trabajo se ha ejecutado correctamente, selecciona el botón Ver registros de trabajo . Esta acción te redirige a Orchestrator, donde puedes ver toda la información necesaria sobre la ejecución del trabajo.

Administrar desencadenadores

Las siguientes acciones están disponibles para los desencadenadores creados en Integration Service.

Cambiar el nombre de un desencadenador

Para cambiar el nombre de un desencadenador, sigue los siguientes pasos:

  1. Access the Triggers tab.
  2. Pasa el cursor del ratón sobre el nombre del desencadenador que deseas modificar. Se mostrará el botón Editar .

Como alternativa, puedes seleccionar tu desencadenador de la lista para acceder a la vista detallada. El botón Editar se encuentra a la derecha del nombre de tu desencadenador. 3. Selecciona el botón Editar y podrás elegir un nuevo nombre para tu desencadenador

Eliminar un desencadenador

Ve a la pestaña Desencadenadores en la ventana de Integration Service . Selecciona el botón Más acciones correspondiente a tu desencadenador y selecciona Eliminar.

Activar o desactivar un desencadenador

Para activar o desactivar un desencadenador, primero debes seleccionarlo para ver sus detalles. A continuación, selecciona el interruptor situado en la parte superior izquierda de la ventana.

Argumentos del evento

Los desencadenadores desconectados te permiten recuperar datos sobre el conector y el evento que desencadena un proceso.

Si quieres conocer el conector, evento, tipo de registro o registro real que desencadenó el proceso en tu flujo de trabajo, define los siguientes argumentos de entrada de tipo String en tu proceso. Integration Service los rellena automáticamente cuando inicia el trabajo:

  • UiPathEventConnector : determina qué conector inició la automatización.
  • UiPathEvent : determina el tipo de evento que se ha producido.
  • UiPathEventObjectType : define el tipo de registro específico resultante del evento.
  • UiPathEventObjectId - Provides the unique identifier for the object involved in the event.
Nota:

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

No se puede asignar ningún valor a estos argumentos. Se rellenan automáticamente en el momento de la ejecución del desencadenador y no se pueden ver ni editar desde el panel Argumentos en Studio. Obtén más información sobre cómo funcionan los argumentos y cómo gestionarlos en la documentación de Studio: Gestionar argumentos.

Para recuperar y trabajar con un registro que tiene un desencadenador en una ejecución de trabajo, utiliza el argumento de entrada UiPathEventObjectId para recuperar el registro del sistema de origen.

Este es un ejemplo de cómo Integration Service pasa los valores de los argumentos de entrada a los registros de Orchestrator:

docs image

Salidas específicas del desencadenador

Los desencadenadores conectados tienen salidas específicas de objetos. Por ejemplo, el desencadenador Correo electrónico recibido de Microsoft OneDrive & SharePoint genera un objeto de tipo Office365Message, con propiedades como AttachmentsNamesList, FromAddress, InternetMessageId, SentDateTime etc. Para obtener más información, consulta Eventos de Microsoft OneDrive y SharePoint.

Utiliza el Editor de expresiones en Studio para ver todas las propiedades disponibles para cualquier objeto de salida del desencadenador.

Preguntas frecuentes

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.

Nota:

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.

Nota:

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

Por ejemplo:

  • Create a filter in Studio Web:

    trigger-filter-Studio

  • Create a filter in Orchestrator:

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

    Nota:

    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.

Limitaciones

Las limitaciones de los desencadenadores se documentan en la sección Resolución de problemas de esta guía. Consulta Limitaciones del desencadenador.

¿Te ha resultado útil esta página?

Conectar

¿Necesita ayuda? Soporte

¿Quiere aprender? UiPath Academy

¿Tiene alguna pregunta? Foro de UiPath

Manténgase actualizado