Quando você conecta o Fin ao Zendesk, um conjunto de triggers é criado automaticamente no seu workspace do Zendesk. Esses triggers gerenciam como os tickets são atribuídos ao Fin, como o Fin é notificado sobre atualizações e como os status dos tickets mudam enquanto o Fin trabalha.
Importante: Modificar certos triggers incorretamente pode comprometer a capacidade do Fin de responder aos tickets. Este artigo explica o que cada trigger faz e o que é seguro alterar.
Triggers do Fin no Zendesk
Trigger | Propósito | Posso editar? |
Quando novos tickets são criados, atribua-os ao Fin | Encaminha novos tickets para o Fin tratar | Sim — apenas condições |
Quando um ticket é criado com o assunto "Fin Test", atribua ao Fin | Permite testar se o Fin está funcionando | Não |
Quando há atualizações em uma conversa que o Fin está atribuído, notifique o Fin | Informa ao Fin quando um cliente responde | Não modifique |
Quando o Fin resolve um ticket, marque como Solved | Atualiza o status do ticket após o Fin resolvê-lo | Não modifique |
Quando o Fin não resolve um ticket, marque como Pending | Atualiza o status do ticket quando o Fin não consegue resolver | Não modifique |
Quando o Fin não fornece uma resposta, marque como Open | Atualiza o status do ticket quando o Fin não tem resposta | Não modifique |
Quando um ticket de Messaging é criado, encerrado ou resolvido, notifique o Fin | Notifica o Fin sobre tickets do canal de mensagens | Não modifique |
O Trigger de Atribuição
Nome do trigger: Quando novos tickets são criados, atribua-os ao Fin
Este é o único trigger que você deve modificar, e somente adicionando condições para controlar quais tickets o Fin trata.
O que ele faz
Quando um novo ticket é criado no Zendesk, este trigger o atribui ao Fin para que o Fin possa responder. Ele está desativado por padrão — você o ativa quando estiver pronto para o Fin começar a tratar os tickets.
Condições padrão
O ticket foi criado agora (não atualizado)
O ticket não veio de um canal de mensagens (esses são tratados por um trigger separado)
O ticket não está marcado com fin-routed-to-team (impede que o Fin pegue tickets que já foram entregues a um humano)
O que você pode alterar com segurança
Você pode adicionar condições para filtrar quais tickets o Fin recebe. Por exemplo:
Por marca: Atribua o Fin apenas a tickets de uma marca específica
Por grupo: Atribua o Fin apenas a tickets de um grupo específico
Por formulário: Atribua o Fin apenas a tickets enviados por um formulário específico
Por canal: Atribua o Fin apenas a tickets de email, formulário web, etc.
Por tags: Exclua tickets marcados como "vip" ou "urgent" do Fin
Por campos personalizados: Use qualquer campo personalizado do ticket para filtrar
O que você NÃO deve alterar
A ação de atribuição. O trigger deve atribuir o ticket ao usuário Fin. Se você remover ou alterar essa ação, o Fin não receberá nenhum ticket.
As condições padrão existentes. Não remova a exclusão do canal de mensagens nem a verificação da tag fin-routed-to-team — isso evita conflitos com outros triggers e impede que tickets voltem para o Fin após a transferência.
O Trigger de Teste
Nome do gatilho: Quando um ticket é criado com o assunto "Fin Test", atribuir a Fin
Este gatilho existe para que você possa testar Fin sem ativar o gatilho principal de atribuição. Crie um ticket com o assunto "Fin Test" e ele será atribuído a Fin independentemente de outras condições.
Não modifique este gatilho. É um gatilho utilitário simples — não há nada para personalizar.
O Gatilho Webhook
Nome do gatilho: Quando houver atualizações em uma conversa que Fin está atribuído, notificar Fin
O que ele faz
Quando um cliente responde a um ticket que Fin está atribuído, este gatilho envia uma notificação webhook para o Intercom para que Fin possa ler a mensagem e responder. Sem este gatilho, Fin não tem como saber que o cliente disse algo.
Por que você não deve modificá-lo
Remover a ação webhook desconecta Fin completamente — ele nunca responderá a mensagens de acompanhamento
Alterar as condições pode fazer com que Fin perca atualizações ou seja notificado sobre os tickets errados
O gatilho exclui as próprias atualizações de Fin para evitar loops de notificação
Gatilhos de Status
Estes três gatilhos funcionam juntos para atualizar os status dos tickets enquanto Fin processa uma conversa. Eles correspondem diretamente ao ciclo de vida de resolução do Fin.
Quando Fin resolve um ticket, marque como Resolvido
Dispara quando Fin determina que respondeu com sucesso à pergunta do cliente. Ele:
Define o status do ticket como Resolvido
Adiciona a tag fin-resolved
Este gatilho verifica as tags internas de resolução do Fin (fin-soft-resolution, fin-hard-resolution ou fin-redirected-to-ticket) e só dispara em atualizações via API — ou seja, responde apenas às ações do Fin, não a mudanças manuais.
Quando Fin não resolve um ticket, marque como Pendente
Dispara quando Fin respondeu a um ticket mas não forneceu uma resposta — por exemplo, Fin fez uma pergunta para esclarecimento, cumprimentou o cliente ou respondeu sem resolver a consulta. Ele:
Define o status do ticket como Pendente
Adiciona a tag fin-unresolved
Isso significa que Fin ainda está envolvido com o ticket, mas ainda não resolveu a consulta. O ticket permanece visível para sua equipe para que possam monitorá-lo, mas Fin pode resolvê-lo em uma próxima interação.
Quando Fin não fornece uma resposta, marque como Aberto
Dispara quando Fin não encontra uma resposta relevante ou quando um cliente responde após a transferência. Ele:
Define o status do ticket como Aberto
Adiciona a tag fin-unresolved
Isso garante que os tickets não fiquem presos — eles aparecem na fila da sua equipe para acompanhamento.
Por que você não deve modificar esses gatilhos
Alterar os status quebra a capacidade do Fin de rastrear onde cada ticket está em seu ciclo de vida
Remover ou alterar tags faz com que os gatilhos disparem incorretamente ou entrem em loop. Tags como fin-resolved, fin-pending, fin-routed-to-team e fin-unresolved são como Fin e esses gatilhos comunicam o estado entre si.
Alterar a condição "via API" pode fazer com que o gatilho dispare em ações manuais do agente, não apenas nas atualizações do Fin
O Gatilho de Ticket de Mensagens
Nome do gatilho: Quando um ticket de Mensagens é criado, encerrado ou resolvido, notificar Fin
O que ele faz
Este gatilho lida com tickets que chegam pelos canais de mensagens do Zendesk (chat, social, etc.) em vez de e-mail/formulário web. Ele notifica Fin quando:
Um novo ticket de mensagens é criado
Uma sessão de mensagens termina
Um ticket de mensagens é resolvido
Também passa informações da pesquisa CSAT para que Fin possa acompanhar a satisfação do cliente.
Por que você não deve modificá-lo
As condições deste gatilho são especificamente ajustadas para IDs de canais de mensagens e estados de sessão. Modificá-lo pode fazer com que Fin perca tickets de mensagens completamente ou falhe em coletar dados CSAT.
Solução de problemas dos Gatilhos Zendesk do Fin
Fin parou de responder aos tickets
Verifique se o gatilho de atribuição (Quando novos tickets são criados, atribua-os a Fin) está ativo (habilitado).
Verifique se a ação de atribuição ainda aponta para o usuário Fin — se isso foi removido ou alterado, Fin não receberá tickets.
Verifique se o gatilho webhook ainda está ativo — sem ele, Fin não pode ver as respostas dos clientes.
Tickets estão presos em um status
Verifique se os gatilhos de resolução, pendente e aberto não foram modificados.
Procure tags ausentes — se as tags fin-resolved, fin-pending ou fin-unresolved foram removidas das ações dos gatilhos, as transições de status irão falhar.
Fin continua respondendo após passar para um humano
Verifique se a condição da tag fin-routed-to-team ainda está presente no gatilho de atribuição.
Esta tag impede que o Fin pegue tickets que já foram entregues à sua equipe.
Fin não está lidando com tickets de mensagens
Verifique se o gatilho de ticket de mensagens está ativo e não modificado.
Verifique se seu canal de mensagens está incluído nas condições do gatilho.
Dica: Se você ainda estiver com problemas, use o diagnóstico de saúde do gatilho nas configurações do administrador do Intercom para comparar seus gatilhos Zendesk atuais com a configuração esperada. Isso destacará exatamente quais gatilhos foram modificados e o que precisa ser restaurado.