Um gatilho é avaliado somente na fase em que foi criado; ele não é reaplicado automaticamente em outras fases.
A API aceita a criação de dois ou mais gatilhos do mesmo type na mesma fase, sem retornar erro. Quando mais de um gatilho do mesmo tipo dispara para o mesmo evento, o resultado é não determinístico — no caso de set-labels, por exemplo, prevalece a última escrita. Antes de criar um gatilho novo, recomendamos sempre listar os gatilhos existentes na fase (GET /v1/triggers/phases/{phaseId}) e atualizar o gatilho já existente em vez de criar um duplicado.
Mover um card diretamente pela API, fora da interface, não dispara automaticamente os gatilhos do tipo move-card configurados na fase de destino. Esse disparo só ocorre quando o card é movido pela interface, ou por uma automação encadeada (ação move-card executada por outro gatilho).
A atualização (PUT) substitui integralmente as ações do gatilho — ações não incluídas no payload deixam de existir após a atualização. Recomendamos sempre reenviar a lista completa de ações, mesmo as que não mudaram.
Recomendamos criar gatilhos sempre por último na configuração de um flow, depois que fases, campos, motores, pareceres e alçadas de aprovação já estiverem configurados, já que as condições costumam referenciar esses recursos.
O formato esperado em target varia conforme o type do gatilho: em save-phase-fields, campos de seleção (SELECT, RADIO, CHECKLIST) devem usar condition:"in" com target como array, mesmo para escolha única; em save-opinion e save-approval, o valor costuma ser uma string simples (por exemplo, target:"approved").
Os operadores unários is-empty e is-not-empty usam hífen, não sublinhado — a forma com sublinhado é rejeitada. Recomendamos enviar target explicitamente nesses casos (por exemplo, um array vazio) em vez de omitir a chave.
Remover um gatilho não é reversível pela API. Antes de remover, vale revisar se alguma automação do flow depende dele — principalmente ações move-card responsáveis por avançar cards automaticamente entre fases.
