Gatilhos

Os gatilhos fornecem um mecanismo uniforme para se inscrever em eventos das plataformas de Conector. Isso dá a você a flexibilidade para iniciar automaticamente automações no Orchestrator.

Gatilhos no Orchestrator

Importante:

A partir do final de abril de 2025, é possível criar novos gatilhos do Integration Service apenas no Orchestrator. Os gatilhos criados no Orchestrator não serão listados na aba Gatilhos do Integration Service. Os gatilhos do Integration Service existentes continuarão a ser executados e permanecerão visíveis na aba Gatilhos do Integration Service até 31 de julho de 2025 (essa data está sujeita a possíveis extensões). Após essa data, os gatilhos existentes do Integration Service serão migrados para o Orchestrator, e a aba Gatilhos no Integration Service será removida. Essa alteração é programada para ficar disponível primeiro para os usuários Community e, em seguida, para os usuários Enterprise progressivamente, dependendo da organização e das regiões do tenant. Siga o guia de notas de versão do Integration Service para saber quando a alteração é anunciada pela primeira vez.

Principais benefícios dos gatilhos no Orchestrator

Mover os gatilhos do Integration Service para o Orchestrator é uma grande mudança, mas ela traz muitos benefícios. Estes são os principais motivos que impulsionaram esta atualização:

1. Mapeamento de conta-máquina: o Orchestrator habilita o controle no nível da máquina sobre processos disparados pelo Integration Service.
2. Controle de execução de processos específico por robô: o Orchestrator permite especificar qual robô deve executar um processo em uma pasta na qual vários robôs estão alocados. Isso fornece controle preciso sobre qual robô executa um processo disparado, elimina a necessidade de soluções alternativas, como pastas de robô único, e melhora a escalabilidade ao permitir vários robôs sem perder o controle de execução.
3. Argumentos de entrada e alocação de processos dinâmicos: o Orchestrator habilita argumentos de entrada dinâmicos e permite que você defina o número máximo de instâncias de processos ativas. Isso reduz a duplicação de processos ao permitir argumentos dinâmicos, otimiza o uso de recursos limitando os processos ativos e melhora a eficiência para processos que gerenciam solicitações sequenciais.
4. Gerenciamento aprimorado de processos de longa duração: os gatilhos criados no Orchestrator suportam as opções "Interromper após" e "Encerrar após", permitindo o encerramento automático de processos após uma duração ou condição especificada. Isso impede o uso excessivo de recursos ao encerrar processos de longa duração e garante a execução no tempo certo ao interromper fluxos de trabalho que não respondem.
5. Recursos de edição: o Orchestrator permite que você edite gatilhos existentes.
6. Experiência de gatilhos unificada: crie e gerencie todos os tipos de gatilhos a partir de um local.
7. Visualização de gatilho único: mover a criação de gatilho para o Orchestrator garante que todos os gatilhos baseados no Integration Service mantenham uma única visualização. Agora você pode criar um gatilho baseado no Integration Service de duas maneiras: a partir do Integration Service, criando um gatilho para um conector específico, e a partir do Studio, usando uma atividade Trigger para iniciar uma automação. As informações de configuração exibidas para os dois gatilhos podem diferir ligeiramente, mesmo que capturem o mesmo evento.

Visão geral

Há dois tipos de gatilhos de eventos baseados em conexões do Integration Service:

• Conectado — Criado com atividades de disparo no Studio, usado dentro de um processo.
• Desconectado — Criado no Orchestrator ou Integration Service, usado para iniciar qualquer automação.

Observação:

Os gatilhos dependem de conexões. Excluir uma conexão também exclui todos os gatilhos associados.

Pré-requisitos

Antes de configurar os gatilhos, certifique-se de que as seguintes condições sejam atendidas:

• Integration Service is enabled and provisioned for your tenant.
• You have already set up an Unattended or Non-production Robot in your Orchestrator instance.
• Você está usando pastas modernas (os processos dentro de pastas clássicas não ficam visíveis ao definir gatilhos).
• 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}

   Observação:

   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.

Criação de gatilhos

Você cria gatilhos de eventos desconectados diretamente do Orchestrator. Para obter detalhes, consulte a seção Gatilhos de eventos no guia do usuário do Orchestrator.

O Orchestrator fornece o gerenciamento direto desses gatilhos. No Integration Service, sua única opção para a modificação de gatilhos é ajustar o intervalo de pesquisa, que é definido no nível de conexão.

Atualização do intervalo de pesquisa

Os conectores suportam eventos por meio de um mecanismo de pesquisa.

Quando você configura um gatilho de evento em uma conexão, o intervalo de pesquisa é definido por padrão como 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.

A sondagem é executada na conexão no intervalo selecionado. Após os dados serem recuperados, todos os gatilhos ativos para essa conexão são aplicados ao conjunto de dados. Se uma pesquisa estiver em execução quando você alterar o intervalo, o serviço aguardará a pesquisa existente terminar e, então, iniciará outra.

Para atualizar o intervalo de pesquisa:

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

Exibição do histórico de execução de gatilhos

Importante:

A tabela Histórico de tentativas está disponível exclusivamente para gatilhos criados no Integration Service e listados na aba Gatilhos . O histórico de tentativas não está disponível para gatilhos criados no Orchestrator.

Para visualizar o histórico de execução do gatilho:

1. No Integration Service, selecione a guia Gatilhos .
2. Para qualquer gatilho listado, selecione Exibir gatilho usando o Menu Mais ações:

A tabela Histórico de tentativas mostra:

• A hora do evento - quando o evento foi capturado
• O número de tentativas
• O estado do gatilho - se o processo foi iniciado com sucesso ou não.

Observação:

O estado Bem-sucedido indica apenas que o trabalho foi iniciado com sucesso. Não reflete se o trabalho foi executado com sucesso até o final ou não. Caso um trabalho falhe ao iniciar, seu Estado aparecerá como Falhado. Passe o cursor do mouse sobre o estado Com falha para visualizar a mensagem de erro.

Para verificar se um trabalho foi executado com sucesso, selecione o botão Exibir logs de trabalho . Essa ação redireciona você para o Orchestrator, onde você pode ver todas as informações necessárias sobre a execução de trabalhos.

Gerenciar gatilhos

As seguintes ações estão disponíveis para gatilhos criados no Integration Service.

Os gatilhos criados diretamente no Orchestrator podem ser gerenciados a partir do Orchestrator.

Renomeando um disparador

Para renomear um gatilho, siga as seguintes etapas:

1. Access the Triggers tab.
2. Passe o cursor do mouse sobre o nome do gatilho que você deseja modificar. O botão Editar é exibido. Ou então, você pode selecionar seu gatilho na lista para acessar a visualização detalhada. O botão Editar está localizado no lado direito do nome de seu gatilho.
3. Selecione o botão Editar e poderá escolher um novo nome para o seu gatilho

Exclusão de um gatilho

Vá para a guia Gatilhos na janela Integration Service . Selecione o botão Mais ações correspondente ao seu gatilho e selecione Excluir.

Ativar ou desativar um gatilho

Para ativar ou desativar um gatilho, primeiro você precisa selecioná-lo para exibir seus detalhes. Em seguida, selecione o botão localizado no lado superior esquerdo da janela.

Argumentos de evento

Os gatilhos desconectados permitem que você recupere dados sobre o conector e o evento que dispara um processo.

Se você quiser saber o conector, evento, tipo de registro ou registro real que disparou o processo em seu fluxo de trabalho, defina os seguintes argumentos de entrada do tipo String em seu processo. O Integration Service as preenche automaticamente quando inicia o trabalho:

• UiPathEventConnector - Determina qual conector iniciou a automação.
• UiPathEvent – Determina o tipo de evento que ocorreu.
• UiPathEventObjectType - Define o tipo de registro específico resultante do evento.
• UiPathEventObjectId - Provides the unique identifier for the object involved in the event.

Observação:

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

Você não pode atribuir qualquer valor a esses argumentos. Eles são preenchidos automaticamente no tempo de execução do gatilho e você não pode visualizá-los ou editá-los no painel Argumentos no Studio. Saiba mais sobre como os argumentos funcionam e como gerenciá-los na documentação do Studio: Gerenciamento de argumentos.

Para recuperar e trabalhar com um registro que possui um gatilho em uma execução de trabalho, use o argumento de entrada UiPathEventObjectId para recuperar o registro do sistema de origem.

Aqui está um exemplo de como o Integration Service passa os valores do argumento de entrada para os logs do Orchestrator:

Saídas específicas do gatilho

Os gatilhos conectados têm saídas específicas do objeto. Por exemplo, o gatilho Microsoft OneDrive & SharePoint Email Recebido gera um objeto do tipo Office365Message, com propriedades como AttachmentsNamesList, FromAddress, InternetMessageId, SentDateTime etc. Para obter detalhes, consulte Microsoft OneDrive & SharePoint.

Use o Editor de Expressão no Studio para visualizar todas as propriedades disponíveis para qualquer objeto de saída de gatilho.

Limitações

As limitações do gatilho estão documentadas na seção Solução de problemas deste guia. Consulte Limitações de gatilho.

Perguntas frequentes

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.

Observação:

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.

Observação:

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

Por exemplo:

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

  Observação:

  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.