When a Fin Procedure doesn't resolve a conversation as expected, you can use built-in inspection tools to investigate Fin's decision-making logic. Use this guide to identify where a flow went off track and how to refine your instructions.

What you'll learn

Debug Procedure failures using Fin's thoughts and conversation events.
Diagnose common issues like wrong Procedure triggers, out-of-sequence steps, and branching failures.
Troubleshoot Data connector errors, including auth failures and missing data.
Validate fixes before going live using Simulations.

Accessing the conversation debugger

To understand why Fin took a specific action, you must first enable technical visibility within the conversation thread.

Open the specific conversation in the Inbox.
Click the three dots icon at the top right of the conversation header.
Select Show conversation events.

Tip: Use the keyboard shortcut ⌘ + E (Mac) or Ctrl + Shift + E (Windows) to toggle this view.

Inspecting "Fin's thoughts"

Once conversation events are visible, you can see the reasoning behind every step Fin took during a Procedure. To trace Fin’s decision-making process, locate the Fin's thoughts events in the conversation timeline. These events summarize Fin’s reasoning before it sends a message or performs an action.

For more granular detail, click the Fin Thoughts and click See more. This reveals:

The current step: The specific Procedure step Fin was executing.
Intent interpretation: How Fin understood the customer’s request.
Logic path: Why Fin decided to skip a step, revisit a previous one, or move to a specific branch.

Note: This article covers troubleshooting for Fin Procedures only. The "Fin's thoughts" timeline and debugger are only available when a Procedure was triggered. If Fin gave an unexpected answer in a standard conversation, these tools will not be present in the conversation events.

Common Procedure failures

If Fin is not working as expected, it's usually due to how instructions are phrased or how logic is branched.

Procedure isn't triggering at all

Before reviewing the numbered failures below, run through these basics first:

Check the procedure is published: Draft procedures won't trigger for customers. Confirm the status is set to Published in the editor.
Check Fin is deployed: If Fin is not enabled through the Simply Deploy section, or the "Let Fin handle" step isn't live in your workflow, Fin won't run any procedures.
Check audience targeting: A common miss is targeting Users when the customer is a Lead (or vice versa). In the "When to use this procedure" section, click the audience button and verify the correct audience type and channel are selected.
Check for higher-priority workflows: Active workflows run before Fin evaluates procedure intent. Review your workflows to make sure none are intercepting the conversation before Fin can trigger the procedure.
Review trigger criteria scope: Criteria that are too narrow prevent Fin from matching valid customer messages. Check the "When to use this procedure" description and add positive examples (messages that should trigger it) and negative examples (messages that should not).

Note: While Slack may appear as a selectable channel, procedure triggers are not currently supported for Slack conversations.

Fin triggers the wrong Procedure

Problem: Fin starts a Procedure that doesn't match the customer's request.

Solution: Review your "When to use this procedure" instructions. Use positive and negative examples to help Fin distinguish between similar intents. If a new procedure shares similar trigger criteria with an existing published procedure, the published one may take priority. To isolate the new procedure during testing: temporarily exclude your test user from the existing procedure by adjusting its audience criteria, or narrow the new procedure's trigger to a unique phrase only you would send. Use Fin's thoughts > Expand thoughts in the conversation debugger to confirm which procedure actually fired.

Steps out of sequence

Problem: Fin skips a prerequisite step or moves to a resolution prematurely.

Solution: Check for ambiguity in your natural language instructions. If a step relies on a specific piece of data, ensure the instruction explicitly states: "Only proceed if [data] is provided."

Branching logic failures

Problem: Fin follows the "Else" path when it should have followed the "If" path.

Solution: Inspect the Conditions. If using natural language for branching, try rephrasing for clarity. For complex logic (e.g., date calculations), consider using Python code blocks to enforce strict deterministic rules.

Help Center content taking priority

Problem: Fin answers from the Help Center instead of running the procedure, even when the customer's intent clearly matches the procedure's trigger criteria.

Solution: If Fin is defaulting to a Help Center answer instead of running the procedure, there are two approaches depending on your setup. Try Option 1 first — if the issue persists, move to Option 2.

Option 1: Enable Procedure Switching
Agentic Switch is a per-procedure setting that allows Fin to automatically switch from the current procedure to another live procedure when it detects that a customer's intent has changed mid-conversation — rather than staying locked to the original procedure or falling back to a Help Center answer. When enabled:
- Fin reviews the conversation and all live procedure trigger descriptions to decide when switching would better serve the customer
- If multiple procedures could apply, Fin may ask a clarifying question to select the best one
- Only the source procedure (the one Fin is switching out of) needs the setting on
- The @Switch command can still be used to switch manually
To enable it: Fin AI Agent > Train > Procedures > Settings > Agentic Switch

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

Para identificar o conteúdo conflitante:
- Encontre a conversa na sua Inbox e abra Fin's thoughts.
- Procure referências a artigos do Help Center no caminho de resposta.
- Remova o artigo conflitante ou atualize-o para direcionar os clientes a entrar em contato com o suporte, para que o Fin redirecione para o procedimento em vez disso.

Exemplo: Uma empresa tem um procedimento que trata 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 do Help Center intitulado "Como faço para obter um reembolso?" que explica a política de reembolso. Quando um cliente envia "Gostaria de um reembolso", o 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á orientá-lo" remove a resposta conflitante e direciona os clientes ao procedimento em vez disso.

O procedimento trava ou sai antes de completar

Problema: O procedimento atinge um determinado passo e para, ou sai para um estado final sem completar todos os passos esperados.

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 "Proceder imediatamente": Se vários passos incluem instruções como "proceder imediatamente para o próximo passo", o Fin pode reavaliar passos já concluídos em vez de avançar. Remova essas declarações e deixe o Fin percorrer o procedimento naturalmente com base no fluxo.
Instruções de pular passos: Frases como "voltar para o passo 2" ou "repetir o passo de verificação" podem fazer o Fin entrar em loop entre passos em vez de avançar. Projete cada passo para que haja um caminho claro para frente.
Lógica de condição sobreposta: Se duas condições puderem ser verdadeiras ao mesmo tempo, o 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 ponto.
Subprocedimento que sai sem continuar: Se um subprocedimento é concluído, mas o procedimento principal não tem uma instrução clara sobre o que fazer em seguida, o Fin pode tratar o fim do subprocedimento como o fim de todo o fluxo. No passo que chama o subprocedimento, adicione uma instrução explícita: "Quando o subprocedimento for concluído, continue para [nome do próximo passo]."

Use Fin's thoughts > See more no depurador de conversas para identificar exatamente em qual passo o Fin estava quando o procedimento saiu inesperadamente.

Incompatibilidade de tipo de atributo causa falhas ao salvar

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 em dispositivos móveis (iOS) com Procedures

Em dispositivos móveis (iOS), Procedures têm requisitos adicionais:

Users only: Procedures só disparam para Users no mobile — 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 "When to use this procedure", o iOS deve ser selecionado como canal. O procedimento não será acionado no mobile se apenas Web estiver marcado.
Procedure deve estar Publicada: Procedimentos em rascunho não são servidos a 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 executando para o mesmo gatilho de conversa no iOS pode interceptar a conversa antes que o Fin avalie a intenção do procedimento. Reveja 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 executando dentro de um Procedure. Se seu conector passa em testes independentes mas falha durante uma execução ao vivo de Procedure, comece aqui.

Conector funciona em testes mas falha em um Procedure ao vivo

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

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

Credenciais: Re-salve e republice após rotacionar uma chave. Verifique caracteres ocultos como espaços finais em valores de token.
Permissões: Uma alteração recente de segurança no seu sistema externo pode ter removido o acesso.
Lista de permissões de IP: Confirme se os IPs de saída da Intercom estão incluídos. Contate seu gerente de conta para as faixas atuais.

Importante: Se seu conector parar de funcionar sem mudanças do seu lado, verifique se o provedor da API externa (por exemplo, Shopify, Stripe) atualizou ou desaprovou um endpoint.

Erros de autorização 401 e 403

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

Conector parece não estar disparando

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

Conector retorna dados mas o Fin não os utiliza

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

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

Conector não aparece no editor de procedures

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

Solução: Trabalhe nessas verificações em ordem:

Confirme que 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 procedures.
Verifique se pelo menos uma ação está configurada: Um conector sem ações definidas não aparecerá como opção no editor de procedures, mesmo que esteja Live.
Verifique as permissões do seu papel: Alguns papéis podem ver conectores em Settings, mas não conseguem acessá‑los dentro do editor de procedures. Confirme que seu papel tem acesso a ambas as áreas.
Atualize a página: O editor de procedures às vezes precisa de um hard refresh para refletir conectores publicados recentemente. Use ⌘ + Shift + R (Mac) ou Ctrl + Shift + R (Windows).
Contate o suporte da Fin: Se nada do acima resolver, entre em contato com o Fin Support informando 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 procedures.

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

Problema: O data connector 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 a procedure. Se o conector retornar um erro, Fin trata o passo inteiro como irresolúvel e ou escala para um humano ou recorre ao seu comportamento padrão.

Existem duas maneiras 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 a Fin possa usar. Esta é a correção mais confiável porque Fin sempre recebe algo com que pode trabalhar.
Adicione um passo Condition 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 isso.

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

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

Solução: Isso quase sempre é causado por uma “attribute pill” inválida 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 no Attribute Inserter. O editor converte qualquer texto {{...}} em uma pill que parece idêntica a um atributo válido — mas se o identificador não corresponde a um atributo real, ele resolve para vazio em tempo de execução e a URL da requisição torna‑se inválida.

Para corrigir isso:

Abra o conector e inspecione a URL de requisição e o corpo em busca de quaisquer attribute pills.
Exclua quaisquer pills que foram digitadas manualmente e substitua‑as selecionando o atributo correto no seletor Attribute Inserter.
Se sua URL requer o Intercom contact ID, selecione Contact ID (user.id) no seletor — não User ID (user_id). A Contacts API espera o ID de contato gerado pelo Intercom (user.id), não o user ID definido externamente (user_id).

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

Problema: Um passo de data connector executa e retorna os dados esperados, mas o valor não aparece como atributo da conversa — e passos posteriores na procedure não conseguem acessá‑lo.

Solução: Atributos de conversa são definidos no início da conversa e não podem ser atualizados em tempo real enquanto uma procedure está em execução. Um conector executando dentro de uma procedure não pode gravar um novo valor de volta 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 uma saída de passo dentro da procedure. Referencie‑os em instruções de passos subsequentes usando a sintaxe de saída @connector_name. O valor é acessível dentro da procedure — ele apenas não aparecerá como um 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 em vez disso. Observe que a procedure não será retomada após o handoff, então planeje seu fluxo para completar antes de fazer o handoff.

Conector de dados configurado como READ em vez de UPDATE

Problema: A procedure executa mas não coleta ou armazena a entrada do cliente, mesmo que o passo do data connector pareça executar.

Solução: Verifique o tipo de ação do data connector no passo relevante. READ apenas verifica por um valor armazenado existente — não solicitará input ao cliente nem salvará novos dados. UPDATE coleta input do cliente e salva no atributo. Se sua procedure deveria coletar informações do cliente (ex.: um endereço de email, número de pedido ou motivo do contato), altere o tipo de ação para UPDATE.

Manipulação avançada de falhas com status_code

O status_code retornado por uma chamada de data connector é exposto como um atributo de saída. Você pode referenciá‑lo em um Condition step para ramificar com base em códigos de resposta HTTP específicos, dando controle preciso sobre como a 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 apenas quando um código de erro específico for retornado.

Dica: Veja How to write code conditions for Fin Procedures para exemplos de código usando status_code em um Condition step.

Validando correções com Simulações

Antes de definir sua Procedure como live, use Simulations para verificar a correção:

Preview vs. Simulations — qual devo usar? Preview mostra a experiência completa para o cliente. Usar Preview enquanto sua procedure está live pode expor mensagens de passo a clientes reais. Simulations executam a procedure em segundo plano sem saída para o cliente — são a maneira mais segura de validar lógica e correspondência antes de entrar no ar.

Navegue para o Procedure editor e clique em Test.
Execute uma Simulation onde a IA age como o cliente no cenário com falha.
Revise o resultado de aprovação/recusa e o julgamento da IA para confirmar que a lógica é confiável.

Perguntas frequentes

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

Não, a linha do tempo e o depurador “Fin's thoughts” estão disponíveis apenas quando uma Procedure foi acionada. 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 de Data connector são armazenados?

Os logs de resposta do data connector são armazenados por até 14 days por padrão. Se seu workspace tiver requisitos de segurança de dados mais rígidos, a Intercom pode reduzir isso para 7 days mediante solicitação — entre em contato com nossa equipe de Support para habilitar. Acesse seus logs em Settings > Integrations > Data connectors > Logs.

Posso usar Simulations para testar respostas de Data connector?

Sim — Simulations executam a Procedure completa incluindo quaisquer passos de Data connector, tornando‑as a forma mais confiável de validar o comportamento do conector antes de entrar no ar.

Por que minha Procedure está sendo bloqueada por um Workflow?

Workflows são executados antes de Fin avaliar a intenção da procedure. Se um Workflow estiver ativo para o mesmo gatilho de conversa, ele pode direcionar a conversa antes que Fin tenha chance de corresponder uma procedure. Para corrigir: revise seus workflows ativos em busca de gatilhos sobrepostos e garanta que o bloco Let Fin Handle esteja corretamente configurado no caminho do workflow onde você quer que procedures estejam disponíveis.

Por que minha Procedure passou para um humano inesperadamente?

Existem duas maneiras pelas quais uma Procedure 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 Fin detecta forte frustração ou raiva, ou quando o cliente fica preso em um loop repetitivo. Isso sempre é acionado independentemente de como sua Procedure está configurada.
Transferência configurada — Um passo Handoff to team que você adicionou em um ponto específico do Procedimento, ou orientação específica do Procedimento que você escreveu que instrui Fin a transferir em um cenário particular.

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

Por que minha Orientação de Escalada não está sendo acionada dentro de um Procedimento ?

A Orientação de Escalada 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 roda de configurações no canto superior direito do editor de Instructions e clique em Guidance.
Selecione as categorias de orientação em nível de workspace que deseja aplicar, incluindo Handover and escalation.
Fin combinará a orientação de workspace selecionada com qualquer orientação personalizada específica do procedimento que você escreveu.

Observação: O comportamento padrão de escalada do Fin (cliente pede um humano, frustração detectada, loop repetitivo) sempre é acionado dentro de um Procedimento independentemente das configurações de Guidance. O painel Guidance controla sua Orientação de Escalada e Regras de Escalada em nível de workspace apenas.

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

Ambos os passos encerram o Procedimento, mas direcionam a conversa de maneiras diferentes:

Handoff to team — Encerra o Procedimento e entrega a conversa a um colega humano. A conversa então segue o caminho de escalada configurado em seu Deploy workflow após o passo Let Fin handle (bloco Let Fin handle).
Handoff to workflow — Encerra 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 especialistas). O Procedimento não será retomado após a conclusão do Workflow.

Uma transferência de Procedimento é cobrada como um Fin Outcome?

Um Procedimento Fin só é cobrado como um Fin Outcome 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 faz a transferência para uma equipe, colega ou workflow através 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 quantos passos o Fin executou ou quantas perguntas o cliente fez.

Observação: Você não será cobrado se um Procedimento falhar ao concluir, sair sem atingir um desses resultados, um cliente pedir para falar com um humano em qualquer momento, ou a conversa terminar através do comportamento padrão de escalada do Fin ou regras de escalada em nível de workspace.

Para detalhes completos, veja Understanding Fin Outcomes.

Meu Procedimento para no meio da conversa — pode ser que esteja expirando por tempo limite?

Sim. Procedimentos são executados dentro de um bloco Let Fin Handle em seu Workflow, e esse bloco tem um tempo limite de inatividade padrão. Se um cliente demorar mais que isso para responder, o bloco pode fechar antes do término do procedimento. Para corrigir, 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 nem direcionar uma conversa para um. Os dois sistemas são separados: Guidance molda o tom do Fin e as regras de escalada; Procedimentos definem fluxos passo a passo que o Fin segue quando uma intenção específica é identificada.

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 na 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 ficará parado. Aqui está como diagnosticá‑lo:

Abra a conversa no Inbox e habilite Show conversation events (veja "Accessing the conversation debugger" acima).
Em 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 e‑mail: inputs["user"]["email"] — retorna o e‑mail 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 captura erros de sintaxe imediatamente, sem precisar executar uma conversa ao vivo.
Se a condição for avaliada mas direcionar para o ramo errado, adicione um comando 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.

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

Troubleshooting Fin Procedures and Data connectors