Events

Los eventos proporcionan la capacidad de capturar cuando sucede algo durante la ejecución de procesos. Hay tres tipos principales de eventos en los diagramas de procesos: eventos de inicio, intermedios y de finalización.Estos eventos también se denominan eventos de "captura", que reaccionan a un desencadenador, o eventos de "lanzamiento".

UiPath Platform admite los siguientes tipos de eventos e implementaciones:

• Los eventos de inicio se comportan como eventos de captura. Son desencadenados por:
  • Ninguno (inicia el proceso cuando se desencadena manualmente o se inicia a través de Orchestrator)
  • Eventos de mensaje (que esperan por un desencadenador de evento de Integration Service)
    
    
    
    
  • Eventos de temporizador (inicia el proceso en una programación o retraso, según se define en la configuración del desencadenador)

    A Timer start event begins a process based on a defined schedule rather than user or system input. You can configure it using a Timer section that supports three types: Date, Duration, or Cycle.

    For recurring executions, use the Cycle type and specify the Repeat frequency (e.g., hourly, daily) and interval. The At and Repetitions fields allow additional control over timing and limits.

    In the Implementation section, the Action can be set to None if no inbound event is needed, or Wait for connector event if the process should also listen for an external trigger before proceeding. Timer start events are ideal for scheduled automations such as hourly syncs or daily reports. Read more about Integration Services connectors.

    
    
    
    
    
• Los eventos de captura intermedios se comportan de forma similar a los eventos de inicio. Esperan un mensaje, temporizador o desencadenador de API durante la ejecución del proceso. La ejecución se detiene hasta que se recibe el mensaje.
• Los eventos de límite son un tipo especial de evento de captura intermedia adjunto a una tarea. Pueden configurarse como:
  • Eventos de límite con interrupción: cuando se inicia la tarea adjunta, el evento de límite espera a su desencadenador. Si se desencadena mientras la tarea aún se está ejecutando, interrumpe la tarea y continúa a lo largo de la ruta de salida del evento de límite. Los eventos de límite con interrupción pueden ser desencadenados por eventos de Temporizador o Mensaje.

    A timer boundary event allows you to interrupt a task if it takes too long to complete. You can configure the timeout using either a Duration, a specific Date, or a Cycle (for recurring timers).

    In the properties panel, the Type field determines the timer mode, and the Value field accepts ISO 8601 time expressions (e.g., PT1H for one hour). If the timer expires while the task is still running, the process continues along the boundary event’s outgoing path.
    The Implementation section lets you optionally define actions to take when the timeout is triggered, though it's commonly left as None if the follow-up logic is modeled downstream.
    

    

    
    

    A message boundary event listens for a specific message while the activity it’s attached to is still running. If the message arrives, it interrupts the ongoing task and diverts the flow to a separate path.

    You can define the message handling logic in the Implementation section by selecting an available action (e.g., wait for connector event or external input). Use the Inputs and Outputs sections to pass or extract data from the incoming message. You can also use Update variables to modify process data in response to the message. If no message is received, the original task continues uninterrupted.
    

    

    
    
  • Eventos de límite sin interrupción: cuando se desencadenan, crean un nuevo token de ejecución y continúan a lo largo de una ruta paralela sin interrumpir la ejecución de la tarea original. Los eventos de límite sin interrupción pueden ser desencadenados por eventos de Temporizador y Mensaje.
  • Error boundary events: An Error boundary event is used to catch and handle errors that occur in the activity it is attached to. If an error is thrown, control exits the activity and flows down the boundary event path. By default, the Exception is set to Catch all, which means it captures any unhandled error. In most cases, this path acts as a fallback or "ultimate" error-handling route.
  • The Implementation section allows you to optionally define actions (such as logging or notifying), but it can be left as None if no specific execution is required within the boundary event.
    
    
    
    
• Los eventos intermedios de lanzamiento envían activamente un desencadenador. Por ejemplo:
  • Un evento intermedio de lanzamiento de mensaje actúa como Enviar tarea, invocando una ejecución de la API de Integration Service.
• Los eventos de fin marcan la finalización de un proceso y se comportan como eventos de lanzamiento. Pueden ser:
  • Eventos de fin de error, que completan la instancia del proceso y causan errores en el trabajo de Orchestration Runtime (OR).
  • Message end events, which send a message as the process concludes. A Message end event can be configured to execute a connector activity when the process reaches its end.

    By selecting "Execute connector activity" as the implementation action, you can trigger an outbound operation using any connector available in Integration Service—such as Slack, Salesforce, ServiceNow, or others. This is commonly used to notify external systems, update records, send messages, or upload files upon successful or failed process completion. You must select the target Connector, define the Connection, and choose the specific Activity to run. Inputs allow you to pass data to the connector, while Outputs let you capture and store the connector’s response or result for use elsewhere in the process. Read more about Integration Services connectors

    .
    
    
    
    
  • Terminate end event, which cancels all other execution paths/tokens, especially when multiple branches run in parallel. An End event signifies the conclusion of a process path.

    In Maestro, you can optionally define an Implementation action to perform a final activity—such as executing a connector operation, returning data, or triggering a follow-up system. If no action is needed, the implementation can be set to None, which simply ends the process flow.

    The Arguments section allows you to define output values that can be passed to parent processes or used in downstream reporting. End events are flexible and can be used to close both standard and exceptional paths, depending on how the process is modeled.