Quando um Procedure Fin não resolve uma conversa como esperado, você pode usar ferramentas de inspeção integradas para investigar a lógica de tomada de decisão do Fin. Use este guia para identificar onde um fluxo saiu do caminho e como refinar suas instruções.

O que você vai aprender

Depure falhas em Procedures usando os pensamentos do Fin e eventos da conversa.
Diagnostique problemas comuns como gatilhos errados de Procedures, passos fora de sequência e falhas em ramificações.
Solucione erros de conectores de dados, incluindo falhas de autenticação e dados ausentes.
Valide correções antes de entrar em produção usando Simulações.

Acessando o depurador de conversas

Para entender por que o Fin tomou uma ação específica, você deve primeiro ativar a visibilidade técnica dentro do fio da conversa.

Abra a conversa específica na Inbox.
Clique no ícone de três pontos no canto superior direito do cabeçalho da conversa.
Selecione Mostrar eventos da conversa.

Dica: Use o atalho de teclado ⌘ + E (Mac) ou Ctrl + Shift + E (Windows) para alternar essa visualização.

Inspecionando os "pensamentos do Fin"

Uma vez que os eventos da conversa estejam visíveis, você pode ver o raciocínio por trás de cada passo que o Fin tomou durante um Procedure. Para rastrear o processo de tomada de decisão do Fin, localize os eventos pensamentos do Fin na linha do tempo da conversa. Esses eventos resumem o raciocínio do Fin antes de enviar uma mensagem ou executar uma ação.

Para detalhes mais granulares, clique em Fin Thoughts e depois em Ver mais. Isso revela:

O passo atual: O passo específico do Procedure que o Fin estava executando.
Interpretação da intenção: Como o Fin entendeu a solicitação do cliente.
Caminho lógico: Por que o Fin decidiu pular um passo, revisitar um anterior ou seguir para um ramo específico.

Quando o Fin considera um Procedure para a mensagem de um cliente, mas decide não executá-lo, um evento "[nome do Procedure] considerado pelo Fin e recusado" aparece na linha do tempo da conversa junto com os eventos regulares de gatilho. Expanda-o para ler o raciocínio do Fin sobre por que recusou iniciar o Procedure.

Nota: Este artigo cobre solução de problemas apenas para Procedures Fin. A linha do tempo e o depurador dos "pensamentos do Fin" estão disponíveis somente quando um Procedure foi acionado. Se o Fin deu uma resposta inesperada em uma conversa padrão, essas ferramentas não estarão presentes nos eventos da conversa.

Falhas comuns em Procedures

Se o Fin não está funcionando como esperado, geralmente é devido à forma como as instruções são formuladas ou como a lógica é ramificada.

Procedure não está sendo acionado

Antes de revisar as falhas numeradas abaixo, passe por estes básicos primeiro:

Verifique se o procedure está publicado: Procedures em rascunho não serão acionados para clientes. Confirme que o status está definido como Publicado no editor.
Verifique se o Fin está implantado: Se o Fin não estiver habilitado na seção Simply Deploy, ou o passo "Let Fin handle" não estiver ativo no seu workflow, o Fin não executará nenhum procedure.
Verifique o direcionamento do público: Um erro comum é direcionar para Users quando o cliente é um Lead (ou vice-versa). Na seção "When to use this procedure", clique no botão de público e verifique se o tipo de público e o canal corretos estão selecionados.
Verifique se há workflows de prioridade maior: Workflows ativos são executados antes do Fin avaliar a intenção do procedure. Revise seus workflows para garantir que nenhum esteja interceptando a conversa antes do Fin acionar o procedure.
Revise o escopo dos critérios de gatilho: Critérios muito restritos impedem o Fin de corresponder mensagens válidas dos clientes. Verifique a descrição "When to use this procedure" e adicione exemplos positivos (mensagens que devem acioná-lo) e negativos (mensagens que não devem).
Verifique se há uma Diretriz ou Regra de Escalação concorrente: Se a mensagem do cliente também corresponder a uma Diretriz ou Regra de Escalação (Fin AI Agent > Train > Escalations), a escalação tem prioridade — o Fin passa para um humano em vez de acionar o procedure, mesmo quando os critérios de gatilho do procedure são igualmente bons (ou melhores). Revise suas Diretrizes e Regras de Escalação para termos que se sobrepõem aos gatilhos do procedure (por exemplo, ambos focando no mesmo código de erro ou frase), e adicione exemplos positivos e negativos à Diretriz de Escalação da mesma forma que faria para um gatilho de procedure, para que os dois não concorram pela mesma mensagem.

Nota: Embora o Slack possa aparecer como um canal selecionável, gatilhos de procedures não são atualmente suportados para conversas no Slack.

Fin aciona o Procedure errado

Problema: O Fin inicia um Procedure que não corresponde à solicitação do cliente.

Solução: Revise suas instruções em "When to use this procedure". Use exemplos positivos e negativos para ajudar o Fin a distinguir entre intenções semelhantes. Se um novo procedure compartilha critérios de gatilho semelhantes com um procedure publicado existente, o publicado pode ter prioridade. Para isolar o novo procedure durante o teste: exclua temporariamente seu usuário de teste do procedure existente ajustando seus critérios de público, ou restrinja o gatilho do novo procedure a uma frase única que só você enviaria. Use Fin's thoughts > Expand thoughts no depurador de conversas para confirmar qual procedure foi realmente acionado.

Usando o Fin Operator para depurar o acionamento de Procedures

A depuração de conversas do Fin Operator pode dizer exatamente o que aconteceu com um Procedure em uma conversa específica. Pergunte ao Operator sobre uma conversa e ele informa se cada Procedure foi acionado, recusado, já em execução, nunca considerado ou superado por um Procedure ou Diretriz de Escalação com melhor correspondência — e sugere uma correção para o caso aplicável.

Usando o Fin Operator para revisar gatilhos de Procedures

Quando você pede ao Fin Operator para revisar ou escrever o gatilho de um Procedure (a descrição "When to use this procedure" e exemplos), ele sinaliza as duas falhas que mais frequentemente impedem um Procedure de ser acionado: condições formuladas em termos que um cliente não poderia expressar (por exemplo, um status interno de conta que o cliente não saberia mencionar) e uma descrição de gatilho ampla combinada com cláusulas de gatilho restritas que contradizem os próprios exemplos da descrição.

Passos fora de sequência

Problema: O Fin pula um passo pré-requisito ou avança para uma resolução prematuramente.

Solução: Verifique se há ambiguidade nas suas instruções em linguagem natural. Se um passo depende de um dado específico, certifique-se de que a instrução declare explicitamente: "Só prossiga se [dado] for fornecido."

Falhas na lógica de ramificação

Problema: O Fin segue o caminho "Else" quando deveria ter seguido o caminho "If".

Solução: Inspecione as Condições. Se estiver usando linguagem natural para ramificação, tente reformular para maior clareza. Para lógica complexa (por exemplo, cálculos de datas), considere usar blocos de código Python para impor regras determinísticas estritas.

Conteúdo do Help Center tendo prioridade

Problema: O Fin responde com conteúdo do Help Center em vez de executar o procedure, mesmo quando a intenção do cliente corresponde claramente aos critérios de gatilho do procedure.

Solução: Se o Fin está optando por uma resposta do Help Center em vez de executar o procedure, há duas abordagens dependendo da sua configuração. Tente a Opção 1 primeiro — se o problema persistir, passe para a Opção 2.

Opção 1: Ativar troca de Procedures
Agentic Switch é uma configuração por procedimento que permite que Fin mude automaticamente do procedimento atual para outro procedimento ativo quando detecta que a intenção do cliente mudou no meio da conversa — em vez de permanecer preso ao procedimento original ou recorrer a uma resposta do Help Center. Quando ativado:
- Fin analisa a conversa e todas as descrições dos gatilhos dos procedimentos ativos para decidir quando a troca seria melhor para o cliente
- Se vários procedimentos puderem ser aplicados, Fin pode fazer uma pergunta de esclarecimento para selecionar o melhor
- Apenas o procedimento de origem (do qual Fin está mudando para fora) precisa ter a configuração ativada
- O comando @Switch ainda pode ser usado para trocar manualmente
Para ativar: Fin AI Agent > Train > Procedures > Settings > Agentic Switch

Opção 2: Remover ou atualizar o conteúdo conflitante do Help Center
Se ativar o Agentic Switch não resolver o problema, a solução mais confiável é remover ou atualizar o conteúdo do Help Center que o Fin está exibindo em vez de executar o procedimento. Fin usa respostas do Help Center por padrão quando existe conteúdo relevante para um tópico — então, se um artigo cobre a mesma intenção que seu procedimento, Fin pode responder diretamente a partir dele em vez de acionar o procedimento.

Para identificar o conteúdo conflitante:
- Encontre a conversa na sua Inbox e abra os pensamentos do Fin.
- Procure referências a artigos do Help Center no caminho da resposta.
- Remova o artigo conflitante ou atualize-o para direcionar os clientes a contatar o suporte, para que Fin encaminhe para o procedimento em vez disso.

Exemplo: Uma empresa tem um procedimento que lida com pedidos de reembolso - ele coleta o número do pedido, verifica a elegibilidade e processa o reembolso automaticamente. Eles também têm um artigo no Help Center intitulado "Como faço para obter um reembolso?" que explica a política de reembolso. Quando um cliente envia a mensagem "Gostaria de um reembolso", Fin encontra o artigo do Help Center e responde com a explicação da política em vez de acionar o procedimento. Nesse caso, atualizar o artigo para dizer algo como "Para solicitar um reembolso, inicie um chat e nosso assistente irá guiá-lo" remove a resposta conflitante e direciona os clientes para o procedimento.

Procedimento trava ou sai antes de completar

Problema: O procedimento chega a uma determinada etapa e para, ou sai para um estado final sem completar todas as etapas esperadas.

Solução: Isso geralmente é causado por padrões de design que confundem a capacidade do Fin de rastrear onde ele está no procedimento. Verifique o seguinte:

Declarações redundantes de "Prosseguir imediatamente": Se várias etapas incluem instruções como "prosseguir imediatamente para a próxima etapa", Fin pode reavaliar etapas já concluídas em vez de avançar. Remova essas declarações e deixe Fin avançar naturalmente pelo procedimento com base no fluxo.
Instruções de pular etapas: Frases como "voltar para a etapa 2" ou "repetir a etapa de verificação" podem fazer Fin entrar em loop entre etapas em vez de avançar. Projete cada etapa para que haja um caminho claro para frente.
Lógica condicional sobreposta: Se duas condições puderem ser verdadeiras ao mesmo tempo, Fin pode ramificar de forma imprevisível ou travar. Certifique-se de que suas condições sejam mutuamente exclusivas — apenas um ramo deve ser verdadeiro em qualquer momento.
Saídas de subprocedimento sem continuação: Se um subprocedimento for concluído, mas o procedimento principal não tiver uma instrução clara sobre o que fazer em seguida, Fin pode tratar o fim do subprocedimento como o fim de todo o fluxo. Na etapa que chama o subprocedimento, adicione uma instrução explícita: "Quando o subprocedimento for concluído, continue para [nome da próxima etapa]."

Use os pensamentos do Fin > Ver mais no depurador de conversa para identificar exatamente em qual etapa Fin estava quando o procedimento saiu inesperadamente.

Falhas ao salvar causadas por incompatibilidade de tipo de atributo

Problema: O procedimento falha ao salvar uma resposta em um atributo da conversa.

Solução: Verifique se o tipo do atributo corresponde ao valor que o procedimento está tentando salvar. Se o procedimento estiver salvando uma string (por exemplo, uma resposta do cliente coletada durante a conversa), o atributo de destino deve ser do tipo string. Usar um atributo do tipo lista com o mesmo nome causará falhas ao salvar. Para corrigir, atualize o procedimento para referenciar o atributo correto ou vá para Settings > Data > Conversations para alterar o tipo do atributo.

Problemas no mobile (iOS) com Procedures

No mobile (iOS), Procedures têm requisitos adicionais: Quando um Procedure teria sido considerado mas recusado para uma determinada pergunta, o teste em lote mostra "[Nome do Procedure] seria considerado mas recusado em uma conversa real com cliente" ao lado da resposta — clique em Mostrar raciocínio para ver por que Fin não o acionou.

Apenas para Users: Procedures só são acionados para Users no mobile — eles não serão executados para Leads ou Visitors independentemente de como o público está configurado no procedimento.
O canal iOS deve ser direcionado: Na seção "Quando usar este procedimento", iOS deve ser selecionado como canal. O procedimento não será acionado no mobile se apenas Web estiver marcado.
O procedimento deve estar Publicado: Procedimentos em rascunho não são disponibilizados para clientes mobile.
Verifique se o Fin está implantado para iOS: Procedures precisam que o Fin esteja ativo no canal iOS. Confirme se o Simple Deploy está ativado em Fin AI Agent > Deploy > Chat, ou se há um bloco ativo Let Fin Handle no workflow relevante direcionado ao iOS.
Workflows de maior prioridade: Um workflow rodando para o mesmo gatilho de conversa no iOS pode interceptar a conversa antes que Fin avalie a intenção do procedimento. Revise seus workflows ativos para sobreposições no canal iOS.

Solução de problemas de conectores de dados em Procedures

Esta seção cobre falhas específicas de conectores de dados executados dentro de um Procedure. Se seu conector passar em testes isolados mas falhar durante uma execução ao vivo do Procedure, comece por aqui.

Conector funciona em testes mas falha em Procedure ao vivo

Problema: O conector passa nos testes isolados mas falha durante uma execução ao vivo.

Solução: Isso geralmente é causado por um dos seguintes:

Credenciais: Re-salve e republicar após rotacionar uma chave. Verifique por caracteres ocultos como espaços finais nos valores do token.
Permissões: Uma mudança recente de segurança no seu sistema externo pode ter removido o acesso.
Lista de IPs permitidos: Confirme se os IPs de saída da Intercom estão incluídos. Contate seu gerente de conta para obter os intervalos atuais.

Importante: Se seu conector parar de funcionar sem alterações do seu lado, verifique se seu provedor externo de API (ex.: Shopify, Stripe) atualizou ou descontinuou um endpoint.

Erros de autorização 401 e 403

401 Unauthorized: O token está ausente, expirado ou malformado. Intercom tenta novamente automaticamente uma vez. Verifique a aba Logs para confirmar se uma atualização foi tentada.
403 Forbidden: O token é válido mas não tem permissão. Revise as permissões no seu sistema externo.
Usuários OAuth: Use o botão Reauthenticate em vez de deletar e recriar o token.

Conector não parece estar acionando

Verifique os logs: Navegue para Settings > Integrations > Data connectors > Logs. Se não houver entrada de log, a etapa provavelmente foi pulada; verifique a lógica do ramo anterior.
Verifique eventos da conversa: Selecione Logs de qualquer evento de erro na Inbox para detalhes completos.

Conector retorna dados mas Fin não os usa

Use os pensamentos do Fin para ver como Fin interpretou a resposta do conector.
Torne a instrução da etapa mais explícita: "Use @connector_name para responder a isso — não use conteúdo da knowledge base."
Verifique se a resposta está vazia ou nula; Fin pode recorrer a outras fontes se nenhum dado utilizável for encontrado.
Fin chama um conector por vez: Se seu procedimento precisar fazer várias chamadas de conector em sequência, cada chamada deve ser um passo distinto. Fin processa uma chamada de ferramenta por turno de conversa — não pode encadear múltiplas chamadas de conector em uma única instrução de passo.

Importante: Fin só pode processar uma chamada de conector por turno, então se seu servidor MCP enviar duas respostas separadas pelo mesmo fluxo SSE, Fin não poderá usar a primeira resposta de forma confiável para construir sua resposta.

Conector não aparece no editor de procedimento

Problema: Seu conector de dados está publicado e configurado, mas não aparece quando você tenta adicioná-lo a um passo dentro do editor de procedimento.

Solução: Siga estas verificações na ordem:

Confirme se o conector está definido como Live: Vá para Settings > Integrations > Data connectors e verifique o status do conector. Um conector em Draft não aparecerá no editor de procedimento.
Verifique se pelo menos uma ação está configurada: Um conector sem ações definidas não aparecerá como opção no editor de procedimento, mesmo que esteja Live.
Verifique as permissões do seu papel: Alguns papéis podem visualizar conectores em Settings, mas não acessá-los dentro do editor de procedimento. Confirme se seu papel tem acesso a ambas as áreas.
Atualize a página: O editor de procedimento às vezes precisa de um refresh forçado para refletir conectores publicados recentemente. Use ⌘ + Shift + R (Mac) ou Ctrl + Shift + R (Windows).
Contate o Suporte Fin: Se nada disso resolver, entre em contato com o Suporte Fin com o nome do conector e os detalhes do seu workspace. Algumas configurações de workspace exigem um passo manual para tornar um conector disponível dentro do editor de procedimento.

Conector falha no modo de execução automática

Problema: O conector de dados está configurado para rodar automaticamente — sem solicitar ao cliente — mas falha silenciosamente durante uma conversa ao vivo. Fin escala ou dá uma resposta inesperada, e não há erro visível na conversa.

Solução: No modo de execução automática, Fin não pode pular um passo de conector falho e continuar o procedimento. Se o conector retornar um erro, Fin trata o passo inteiro como irresolúvel e ou escala para um humano ou recorre ao comportamento padrão.

Existem duas formas de lidar com isso:

Modifique sua API externa para retornar um valor de fallback: Em vez de retornar um erro quando os dados não estão disponíveis (por exemplo, um 404 quando um pedido não é encontrado), configure sua API para retornar um resultado vazio ou padrão que Fin possa usar. Esta é a correção mais confiável porque Fin sempre recebe algo com que trabalhar.
Adicione um passo de Condição após a chamada do conector: Use a saída status_code do conector para ramificar para uma mensagem amigável ou um caminho de escalonamento controlado quando o conector falhar. Veja "Advanced failure handling with status_code" neste artigo para saber como configurar.

Conector retorna 404 ou atributos de contato não são gravados apesar de parecer executar

Problema: O conector parece disparar — os logs mostram que rodou — mas retorna um erro 404 e os atributos de contato não estão sendo gravados, mesmo que todos os conectores pareçam configurados corretamente.

Solução: Isso quase sempre é causado por um atributo inválido na URL da requisição. Um dos parâmetros da URL está resolvendo para um valor vazio em tempo de execução, tornando a URL malformada.

A causa mais comum: um atributo foi digitado manualmente como {{Attribute Name}} em vez de ser selecionado pelo Inseridor de Atributos. O editor converte qualquer texto {{...}} em um elemento que parece um atributo válido — mas se o identificador não corresponder a um atributo real, ele resolve para vazio em tempo de execução e a URL da requisição fica inválida.

Para corrigir isso:

Abra o conector e inspecione a URL da requisição e o corpo para quaisquer elementos de atributo.
Apague quaisquer elementos que foram digitados manualmente e substitua-os selecionando o atributo correto pelo seletor do Inseridor de Atributos.
Se sua URL requer o ID de contato do Intercom, selecione Contact ID (user.id) no seletor — não User ID (user_id). A API de Contatos espera o ID de contato gerado pelo Intercom (user.id), não o ID de usuário definido externamente (user_id).

A saída do conector não preenche atributos da conversa

Problema: Um passo de conector de dados roda e retorna os dados esperados, mas o valor não aparece como atributo da conversa — e passos posteriores no procedimento não conseguem acessá-lo.

Solução: Atributos da conversa são definidos no início da conversa e não podem ser atualizados em tempo real enquanto um procedimento está em execução. Um conector executando dentro de um procedimento não pode gravar um novo valor em um atributo da conversa no meio da conversa.

O que isso significa na prática:

Use a saída do conector diretamente em passos posteriores: Os dados que seu conector retorna estão disponíveis como saída de passo dentro do procedimento. Referencie-os nas instruções dos passos subsequentes usando a sintaxe de saída @connector_name. O valor é acessível dentro do procedimento — só não aparecerá como atributo da conversa no Inbox.
Para persistir dados em um atributo da conversa: Use um passo Handoff to workflow e defina o valor do atributo dentro do workflow. Note que o procedimento não continuará após o handoff, então planeje seu fluxo para concluir antes do handoff.

Conector de dados configurado para READ em vez de UPDATE

Problema: O procedimento roda mas não coleta ou armazena a entrada do cliente, mesmo que o passo do conector de dados pareça executar.

Solução: Verifique o tipo de ação do conector de dados no passo relevante. READ apenas verifica um valor armazenado existente — não solicita entrada do cliente nem salva novos dados. UPDATE coleta entrada do cliente e salva no atributo. Se seu procedimento deve coletar informações do cliente (ex: endereço de e-mail, número do pedido ou motivo do contato), mude o tipo de ação para UPDATE.

Tratamento avançado de falhas com status_code

O status_code retornado por uma chamada de conector de dados é exposto como um atributo de saída. Você pode referenciá-lo em um passo de Condição para ramificar em códigos HTTP específicos, dando controle preciso sobre como Fin lida com diferentes cenários de falha em vez de depender de um único ramo de sucesso/falha.

Por exemplo, você pode direcionar um 404 (recurso não encontrado) para uma mensagem diferente de um 500 (erro de servidor), ou escalar para um agente humano somente quando um código de erro específico for retornado.

Dica: Veja Como escrever condições de código para Fin Procedures para exemplos de código usando status_code em um passo de Condição.

Validando correções com Simulações

Antes de colocar seu Procedimento no ar, use Simulações para verificar a correção:

Pré-visualização vs. Simulações — qual devo usar? Pré-visualização mostra a experiência completa para o cliente. Usar Pré-visualização enquanto seu procedimento está ativo pode expor mensagens de passos para clientes reais. Simulações executam o procedimento em segundo plano sem saída para o cliente — são a forma mais segura de validar a lógica e o disparo antes de entrar no ar.

Navegue até o editor de Procedimento e clique em Test.
Execute uma Simulação onde a IA atua como cliente no cenário que falha.
Revise o resultado de aprovação/reprovação e o julgamento da IA para confirmar que a lógica é confiável.

Perguntas Frequentes

O depurador de conversa funciona para conversas padrão do Fin?

Não, a linha do tempo e o depurador "Fin's thoughts" estão disponíveis apenas quando um Procedimento foi acionado. Se Fin deu uma resposta inesperada em uma conversa padrão, essas ferramentas não estarão presentes — verifique os eventos da conversa no Inbox em vez disso.

Por quanto tempo os logs do conector de dados são armazenados?

Os logs de resposta do conector de dados são armazenados por até 14 dias por padrão. Se seu workspace tiver requisitos de segurança de dados mais rigorosos, a Intercom pode reduzir isso para 7 dias mediante solicitação — contate nossa equipe de Support para habilitar. Acesse seus logs em Settings > Integrations > Data connectors > Logs.

Posso usar Simulações para testar respostas do conector de dados?

Sim — Simulações executam o Procedimento completo, incluindo quaisquer etapas de conector de Dados, tornando-as a maneira mais confiável de validar o comportamento do conector antes de entrar em produção.

Por que meu Procedimento está sendo bloqueado por um Workflow?

Workflows são executados antes do Fin avaliar a intenção do procedimento. Se um Workflow estiver ativo para o mesmo gatilho de conversa, ele pode direcionar a conversa antes que o Fin tenha a chance de corresponder a um procedimento. Para corrigir isso: revise seus workflows ativos para gatilhos sobrepostos e certifique-se de que o bloco Let Fin Handle esteja configurado corretamente no caminho do workflow onde você deseja que os procedimentos estejam disponíveis.

Por que meu Procedimento passou para um humano inesperadamente?

Existem duas maneiras pelas quais um Procedimento pode passar para um humano:

Comportamento padrão de escalonamento — Fin escala automaticamente com base em sua lógica interna: quando um cliente claramente pede para falar com um humano, quando o Fin detecta forte frustração ou raiva, ou quando o cliente está preso em um loop repetitivo. Isso sempre ocorre independentemente de como seu Procedimento está configurado.
Passagem configurada — Um passo Handoff to team que você adicionou em um ponto específico do Procedimento, ou uma orientação específica do Procedimento que você escreveu que instrui o Fin a passar em um cenário particular.

Se a passagem foi inesperada, use os Fin's thoughts no depurador de conversa para ver qual tipo foi acionado e em qual etapa.

O que acontece quando tanto um Procedimento quanto uma Diretriz de Escalonamento correspondem à mesma mensagem do cliente?

O escalonamento tem precedência. Se a mensagem de um cliente corresponder tanto aos critérios de gatilho de um Procedimento quanto a uma Diretriz de Escalonamento (ou uma Regra de Escalonamento), o Fin passa para um humano em vez de executar o Procedimento — mesmo que o gatilho do Procedimento seja uma correspondência mais próxima ou específica para a mensagem. Esta é uma regra geral de como o Fin resolve intenções concorrentes, não algo que pode ser configurado por Procedimento.

Por exemplo, um Procedimento criado para lidar com solicitações de criação de caso "API Error" não será acionado para um cliente que descreve um erro de API se uma Diretriz de Escalonamento também estiver escrita para identificar a linguagem "API Error" — a Diretriz de Escalonamento vence, e o Procedimento nunca é executado.

Como faço para impedir que uma Diretriz de Escalonamento substitua inadvertidamente meu Procedimento?

Restrinja a Diretriz de Escalonamento para que ela não se sobreponha mais aos critérios de gatilho do Procedimento:

Abra Fin AI Agent > Train > Escalations e revise suas Diretrizes de Escalonamento e Regras de Escalonamento para termos que possam corresponder às mesmas mensagens que o gatilho do Procedimento.
Adicione exemplos positivos específicos (deve escalar) e exemplos negativos (não deve escalar — deve executar o Procedimento em vez disso) à Diretriz de Escalonamento, da mesma forma que você refinaria a seção "Quando usar este procedimento" de um Procedimento.
Se ambos estiverem identificando a mesma frase específica (por exemplo, um código de erro específico), reformule a Diretriz de Escalonamento para excluir mensagens do tipo criação de caso, ou torne os critérios de gatilho do Procedimento mais específicos para que os dois não se sobreponham mais.

Use os Fin's thoughts no depurador de conversa para confirmar se uma escalada ou o Procedimento foi acionado para uma determinada mensagem (veja "Acessando o depurador de conversa" acima).

Por que minha Diretriz de Escalonamento não está sendo acionada dentro de um Procedimento?

A Diretriz de Escalonamento não se aplica dentro de um Procedimento por padrão — você precisa habilitá-la explicitamente no painel Guidance do Procedimento:

Abra seu Procedimento, clique na engrenagem de configurações no canto superior direito do editor de Instructions e clique em Guidance.
Selecione as categorias de orientação no nível do workspace que deseja aplicar, incluindo Handover and escalation.
O Fin combinará a orientação selecionada do workspace com qualquer orientação personalizada específica do procedimento que você tenha escrito.

Nota: O comportamento padrão de escalonamento do Fin (cliente pede um humano, frustração detectada, loop repetitivo) sempre ocorre dentro de um Procedimento independentemente das configurações de Guidance. O painel Guidance controla apenas sua Diretriz de Escalonamento e Regras de Escalonamento no nível do workspace.

Qual é a diferença entre Handoff to team e Handoff to workflow?

Ambos os passos terminam o Procedimento, mas eles direcionam a conversa de forma diferente:

Handoff to team — Termina o Procedimento e passa a conversa para um colega humano. A conversa então segue o caminho de escalonamento configurado no seu workflow Deploy após o passo Let Fin handle (bloco Let Fin handle).
Handoff to workflow — Termina o Procedimento e passa a conversa para um Workflow reutilizável específico que você já criou (por exemplo, uma pesquisa de satisfação ou um fluxo de roteamento para especialista). O Procedimento não será retomado após a conclusão do Workflow.

Uma passagem de Procedimento é cobrada como um Fin Outcome?

Um Procedimento Fin é cobrado como um Fin Outcome somente quando a conversa termina de uma das duas maneiras:

Resolução — o cliente confirma que o Fin resolveu seu problema, ou não pede mais ajuda após o Fin responder.
Procedure Handoff — Fin passa para uma equipe, colega ou workflow por meio de um passo Handoff configurado ou orientação específica do procedimento que você configurou.
Em ambos os casos, você é cobrado $0,99 — e apenas uma vez por conversa, independentemente de quantas etapas o Fin executou ou quantas perguntas o cliente fez.

Nota: Você não será cobrado se um Procedimento não for concluído, sair sem alcançar um desses resultados, um cliente pedir para falar com um humano a qualquer momento, ou a conversa terminar por meio do comportamento padrão de escalonamento do Fin ou regras de escalonamento no nível do workspace.

Para detalhes completos, veja Understanding Fin Outcomes.

Meu Procedimento para no meio da conversa — pode ser um tempo limite?

Sim. Procedimentos são executados dentro de um bloco Let Fin Handle no seu Workflow, e esse bloco tem um tempo limite padrão de inatividade. Se um cliente demorar mais que isso para responder, o bloco pode fechar antes do procedimento ser concluído. Para corrigir isso, abra o bloco Let Fin Handle nas configurações do seu Workflow e aumente o tempo limite de inatividade para corresponder melhor à duração esperada da conversa.

Posso usar Guidance para acionar um Procedimento?

Não. Guidance controla como o Fin responde e se comporta — não pode iniciar um procedimento ou direcionar uma conversa para um. Os dois sistemas são separados: Guidance molda o tom e as regras de escalonamento do Fin; Procedimentos definem workflows passo a passo que o Fin segue quando uma intenção específica é correspondida.

Para alternar de um procedimento para outro no meio da conversa, use o comando @Switch dentro do procedimento de origem, ou habilite Agentic Switch nas configurações do procedimento (veja "4. Help Center content taking priority" neste artigo).

Se você quer que o Fin decida inteligentemente quando chamar um conector de dados ou seguir um fluxo específico com base no que o cliente diz, construa essa lógica em um procedimento em vez de guidance.

Minha condição de código não está ramificando — como faço para depurá-la?

Condições de código falham silenciosamente quando há um erro de sintaxe ou quando o caminho de dados que você está tentando acessar não existe no contexto da conversa. O Fin não exibirá o erro diretamente — ele apenas seguirá o ramo Else ou travará. Veja como diagnosticar:

Abra a conversa na Inbox e habilite Show conversation events (veja "Acessando o depurador de conversa" acima).
Nos Fin's thoughts, verifique qual valor o Fin recebeu como entrada para sua condição. Se o valor for null ou undefined, o caminho de dados no seu código está incorreto.
Verifique estes padrões comuns de acesso a dados: • Endereço de email: inputs["user"]["email"] — retorna o email do cliente se disponível, caso contrário None • Saída do conector: use o nome exato do campo do esquema de resposta do seu conector • Atributo da conversa: inputs["conversation"]["attribute_name"]
Teste seu bloco de código em um interpretador Python antes de adicioná-lo ao procedimento. Isso detecta erros de sintaxe imediatamente, sem precisar executar uma conversa ao vivo.
Se a condição for avaliada mas direcionar para o ramo errado, adicione uma instrução print() no seu bloco de código para registrar o valor real que o Fin está recebendo. A saída aparecerá nos eventos da conversa.

Nota: O tipo de cliente (user vs. lead) não está disponível atualmente como um atributo do Procedimento. Se você precisar ramificar com base no tipo de cliente, use uma condição Type no seu Workflow antes do passo Fin.