Quando uma 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 o 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 Procedure, 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 uma 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 realizar 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 da 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.

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 uma Procedure foi acionada. 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 acionada

Antes de revisar as falhas numeradas abaixo, revise primeiro estes pontos básicos:

Verifique se a procedure está publicada: Procedures em rascunho não serão acionadas para clientes. Confirme que o status está definido como Published 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á nenhuma 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 canal corretos estão selecionados.
Verifique se há workflows de prioridade maior: Workflows ativos são executados antes do Fin avaliar a intenção da procedure. Revise seus workflows para garantir que nenhum esteja interceptando a conversa antes do Fin acionar a procedure.
Revise o escopo dos critérios de gatilho: Critérios muito restritos impedem que o Fin reconheça mensagens válidas dos clientes. Verifique a descrição em "When to use this procedure" e adicione exemplos positivos (mensagens que devem acionar) e negativos (mensagens que não devem acionar).
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 a procedure, mesmo quando os critérios de gatilho da procedure são igualmente bons (ou melhores). Revise suas Diretrizes e Regras de Escalação para identificar termos que se sobrepõem aos gatilhos da procedure (por exemplo, ambos usando o mesmo código de erro ou frase), e adicione exemplos positivos e negativos na Diretriz de Escalação da mesma forma que faria para o gatilho da procedure, para que não concorram pela mesma mensagem.

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

Fin aciona a Procedure errada

Problema: O Fin inicia uma 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 uma nova procedure compartilha critérios de gatilho semelhantes com uma procedure publicada existente, a publicada pode ter prioridade. Para isolar a nova procedure durante testes: exclua temporariamente seu usuário de teste da procedure existente ajustando seus critérios de público, ou restrinja o gatilho da nova 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 acionada.

Passos fora de sequência

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

Solução: Verifique ambiguidades 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ções, tente reformular para maior clareza. Para lógica complexa (ex.: 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 a procedure, mesmo quando a intenção do cliente corresponde claramente aos critérios de gatilho da procedure.

Solução: Se o Fin está retornando uma resposta do Help Center em vez de executar a procedure, existem 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 a Troca de Procedure
Agentic Switch é uma configuração por procedure que permite ao Fin alternar automaticamente da procedure atual para outra procedure ativa quando detecta que a intenção do cliente mudou no meio da conversa — em vez de permanecer preso à procedure original ou retornar a uma resposta do Help Center. Quando ativado:
- O Fin revisa a conversa e todas as descrições de gatilho das procedures ativas para decidir quando a troca beneficiaria mais o cliente
- Se múltiplas procedures puderem se aplicar, o Fin pode fazer uma pergunta de esclarecimento para selecionar a melhor
- Apenas a procedure de origem (da qual o Fin está trocando para fora) precisa ter a configuração ativada
- O comando @Switch ainda pode ser usado para trocar manualmente
Para habilitar: Fin AI Agent > Train > Procedures > Settings > Agentic Switch

Opção 2: Remover ou atualizar o conteúdo conflitante do Help Center
Se habilitar 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. O Fin usa respostas do Help Center quando há conteúdo relevante para um tópico — então, se um artigo cobre a mesma intenção que seu procedimento, o Fin pode responder diretamente por ele 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 o 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", 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á guiá-lo" remove a resposta conflitante e direciona os clientes para o procedimento.

O procedimento trava ou sai antes de completar

Problema: O procedimento chega a 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 "Proceda imediatamente": Se vários passos incluem instruções como "proceda 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 avançar naturalmente pelo procedimento com base no fluxo.
Instruções de pular passos: Frases como "volte para o passo 2" ou "repita o passo de verificação" podem fazer o Fin entrar em loop entre os 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 momento.
Subprocedimento sai sem continuar: Se um subprocedimento termina mas o procedimento principal não tem uma instrução clara do 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 os pensamentos do Fin > Ver mais no depurador de conversas para identificar exatamente em qual passo o 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 está 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:

Apenas para Users: 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 selecionado: Na seção "When to use this procedure", iOS deve estar 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á habilitado 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 do Fin avaliar 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 executando dentro de um Procedure. Se seu conector passa em testes isolados mas falha durante uma execução ao vivo do Procedure, comece aqui.

Conector funciona no teste 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 motivos:

Credenciais: Re-salve e republicar após rotacionar uma chave. Verifique por caracteres ocultos como espaços no final dos 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 do 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. O 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 disparando

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

Conector retorna dados mas o Fin não os usa

Use os pensamentos do Fin para ver como o Fin interpretou a resposta do conector.
Torne a instrução do passo 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; 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 múltiplas chamadas de conector em sequência, cada chamada deve ser um passo distinto. O Fin processa uma chamada de ferramenta por turno de conversa — não pode encadear múltiplas 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 enviar duas respostas separadas pelo mesmo fluxo SSE, o Fin não poderá usar de forma confiável a primeira resposta para construir sua resposta.

Conector não aparece no editor de procedimentos

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

Solução: Execute 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 procedimentos.
Verifique se pelo menos uma ação está configurada: Um conector sem ações definidas não aparecerá como opção no editor de procedimentos, mesmo que esteja Live.
Verifique as permissões do seu papel: Alguns papéis podem visualizar conectores em Settings, mas não conseguem acessá-los dentro do editor de procedimentos. Confirme se seu papel tem acesso a ambas as áreas.
Atualize a página: O editor de procedimentos às vezes precisa de uma atualização forçada para refletir conectores publicados recentemente. Use ⌘ + Shift + R (Mac) ou Ctrl + Shift + R (Windows).
Contate o Fin Support: Se nada do acima resolver, entre em contato com o Fin Support com o nome do conector e os detalhes do seu workspace. Algumas configurações de workspace exigem um passo manual para disponibilizar um conector dentro do editor de procedimentos.

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, o Fin não pode pular um passo de conector que falhou e continuar o procedimento. Se o conector retornar um erro, o Fin trata o passo inteiro como irresolúvel e ou escala para um humano ou volta 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 o Fin possa usar. Esta é a correção mais confiável porque o Fin sempre recebe algo com que pode trabalhar.
Adicione um passo de 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.

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 são gravados, mesmo que todos os conectores pareçam configurados corretamente.

Solução: Isso quase sempre é causado por uma pílula de atributo 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 pelo Attribute Inserter. O editor converte qualquer texto {{...}} em uma pílula que parece idêntica a 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 pílulas de atributo.
Exclua quaisquer pílulas digitadas manualmente e substitua-as selecionando o atributo correto no seletor Attribute Inserter.
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 Contacts 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 data connector 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 do 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 — ele apenas 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.

Data connector 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 data connector pareça executar.

Solução: Verifique o tipo de ação do data connector 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), altere o tipo de ação para UPDATE.

Tratamento avançado 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 em códigos HTTP específicos, dando controle preciso sobre como o 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 Condition step.

Validando correções com Simulações

Antes de colocar seu Procedure no ar, 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 seu procedimento está ativo pode expor mensagens de passos para clientes reais. Simulations 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 de correspondência antes de entrar no ar.

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

FAQs

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 Procedure foi acionado. Se o Fin deu uma resposta inesperada em uma conversa padrão, essas ferramentas não estarão presentes — verifique os eventos da conversa no Inbox.

Por quanto tempo os logs do Data connector são armazenados?

Os logs de resposta do Data connector 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 para 7 dias mediante solicitação — contate nossa equipe de Support para habilitar. Acesse seus logs em Settings > Integrations > Data connectors > Logs.

Posso usar Simulations para testar respostas do Data connector?

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

Por que meu Procedure 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 chance de corresponder a um procedimento. Para corrigir isso: revise seus workflows ativos para gatilhos sobrepostos e garanta que o bloco Let Fin Handle esteja configurado corretamente no caminho do workflow onde deseja que os procedimentos estejam disponíveis.

Por que meu Procedure foi transferido para um humano inesperadamente?

Existem duas formas de um Procedure transferir 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 está preso em um loop repetitivo. Isso sempre ocorre independentemente de como seu Procedure está configurado.
Transferência configurada — Um passo Handoff to team que você adicionou em um ponto específico do Procedure, ou uma orientação específica do Procedure que você escreveu para instruir Fin a transferir em um cenário particular.

Se a transferência 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 Procedure quanto uma Escalation Guideline 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 Procedure quanto a uma Escalation Guideline (ou uma Escalation Rule), Fin transfere para um humano em vez de executar o Procedure — mesmo que o gatilho do Procedure seja uma correspondência mais próxima ou específica da mensagem. Esta é uma regra geral de como Fin resolve intenções concorrentes, não algo que pode ser configurado por Procedure.

Por exemplo, um Procedure 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 Escalation Guideline também estiver escrita para identificar a linguagem "API Error" — a Escalation Guideline vence, e o Procedure nunca é executado.

Como faço para impedir que uma Escalation Guideline substitua inadvertidamente meu Procedure?

Restrinja a Escalation Guideline para que ela não se sobreponha mais aos critérios de gatilho do Procedure:

Abra Fin AI Agent > Train > Escalations e revise sua Escalation Guidance e Escalation Rules para identificar redações que possam corresponder às mesmas mensagens que o gatilho do Procedure.
Adicione exemplos positivos específicos (deve escalar) e exemplos negativos (não deve escalar — deve executar o Procedure em vez disso) à Escalation Guideline, da mesma forma que você refinaria a seção "Quando usar este procedure" de um Procedure.
Se ambos estiverem focando na mesma frase específica (por exemplo, um código de erro específico), reformule a Escalation Guideline para excluir mensagens no estilo de criação de caso, ou torne os critérios de gatilho do Procedure 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 Procedure foi acionado para uma determinada mensagem (veja "Acessando o depurador de conversa" acima).

Por que minha Escalation Guidance não está sendo acionada dentro de um Procedure?

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

Abra seu Procedure, 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.
Fin combinará a orientação selecionada do workspace com qualquer orientação personalizada específica do procedure 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 Procedure independentemente das configurações de Guidance. O painel Guidance controla apenas sua Escalation Guidance e Escalation Rules no nível do workspace.

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

Ambos os passos encerram o Procedure, mas roteiam a conversa de forma diferente:

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

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

Um Procedure do 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 transfere para uma equipe, colega ou workflow via um passo de Handoff configurado ou orientação específica do procedure 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.

Nota: Você não será cobrado se um Procedure 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 pelo comportamento padrão de escalonamento do Fin ou pelas regras de escalonamento no nível do workspace.

Para detalhes completos, veja Understanding Fin Outcomes.

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

Sim. Procedures 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 procedure 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 Procedure?

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

Para alternar de um procedure para outro no meio da conversa, use o comando @Switch dentro do procedure de origem, ou habilite Agentic Switch nas configurações do procedure (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 procedure em vez de usar 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. Fin não exibirá o erro diretamente — ele apenas seguirá o ramo Else ou travará. Veja como diagnosticar:

Abra a conversa no Inbox e habilite Mostrar eventos da conversa (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 procedure. 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 Procedure. Se você precisar ramificar com base no tipo de cliente, use uma condição Type no seu Workflow antes do passo Fin.

Solução de Problemas em Procedures Fin e conectores de Dados