> For the complete documentation index, see [llms.txt](https://docs.caf.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.caf.io/caf-docs/caf-product-guides-pt-br/guia-do-usuario/trust-platform/workflow-builder.md). # Construtor de fluxo de trabalho ### Introdução A criação da ferramenta Workflow Builder tem como objetivo economizar tempo e dinheiro, evitando consultas que seriam rejeitadas logo no início do processo. Ela também permite que os usuários criem o fluxo de validação condicional desejado na sequência de sua preferência. O Workflow substitui o conhecido Query Template, servindo como o modelo/conjunto de regras e serviços necessários que definem o que será validado em nosso treadmill. {% hint style="info" %} **Observação:** esta ferramenta está disponível apenas para contas globais de cliente. {% endhint %} ### Criar um workflow Levando em consideração que a conta da Trust Platform é uma conta global, ou seja, a flag de workflow está habilitada no cliente, para iniciar o processo de criação do workflow, o usuário deve clicar no menu "Tools" e depois selecionar o submenu "Workflow Builder". Ao acessar a tela de workflow, será exibida uma lista de todos os workflows criados anteriormente. Se ainda não houver workflows ou se for necessário criar um novo, comece clicando em "Create Workflow" para definir o tipo de segmentação (atualmente disponível apenas para validação de Pessoas) e atribuir um nome. {% hint style="warning" %} **Importante:** quando uma conta global é criada, um workflow KYB padrão será gerado automaticamente, especificamente para validação de empresas. Nesta etapa inicial, não é possível editar o workflow padrão e, devido à sua natureza padrão, a execução exigirá consistentemente revisão manual do cliente. {% endhint %} Ao contrário do Query Template usado no fluxo do Brasil, o Workflow Builder está interconectado com regras e serviços. Isso significa que, para utilizar um serviço específico, é necessário selecionar uma regra associada a ele e então arrastá-la para uma etapa de validação dentro do Workflow Builder. Fazendo isso, a regra determinará o serviço a ser usado, eliminando a necessidade de etapas separadas para tomar essas decisões. Como mencionado anteriormente, o Workflow cria um fluxo com base em regras e etapas de validação, que podem ser singulares ou condicionais, dependendo dos requisitos de negócio do cliente. 1. **Regras em uma única etapa** Se o cliente desejar criar um workflow com todas as regras e validações em uma única etapa, ele pode fazer isso. Para isso, é necessário arrastar todas as regras necessárias para a etapa inicial e definir suas validações. Em outras palavras, se a regra corresponder, o status a ser exibido deve ser especificado, e o mesmo se aplica caso a regra não corresponda. * **Aprovado:** se este status for selecionado e todas as regras dentro da mesma etapa forem aprovadas, a execução terá um status final de Aprovado. * **Rejeitado:** quando este status for escolhido, se qualquer uma das regras existentes na etapa for rejeitada, a execução terá um status final de Rejeitado. * **Pendente:** se uma regra com este status for selecionada e resultar em um status pendente, será necessária uma ação manual de Aprovar ou Rejeitar para a regra. Só então a execução poderá atingir seu status final. * Observação: todas as regras dentro da mesma etapa serão validadas; o status pendente não interrompe a validação, ele apenas afeta o status final da execução. * **Alerta:** se este status for selecionado, um evento/alerta será disparado pela Trust Platform, informando ao cliente que deve prestar atenção a esta execução. Diferentemente do status Pendente, isso não interromperá o fluxo; a execução continuará realizando consultas e validações nos serviços. Se todas as outras regras aprovarem, o status final será Aprovado. Se qualquer regra rejeitar, o status final será Rejeitado, independentemente da regra de Alerta. * Observação: não será possível alterar o status desta regra. 2. **Regras em etapas condicionais** Para usar o fluxo condicional, em que um novo serviço só será consultado se a validação da etapa anterior for concluída com um status final de Aprovado ou Rejeitado, você precisa adicionar uma nova etapa e seguir a mesma lógica de arrastar e soltar das regras necessárias. Para isso, clique na **"New Step"** opção e crie uma etapa condicional para Rejeitado ou Aprovado. Dependendo do resultado da etapa anterior, o workflow seguirá o fluxo condicional predefinido. É fundamental definir os status de Match, pois o Workflow depende deles para prosseguir. No caso de etapas condicionais: * **Aprovado:** se este status for selecionado dentro das regras, quando a etapa tiver um status final de Aprovado, as próximas etapas configuradas para esta condição poderão começar a ser processadas. O status final da execução só será determinado após todas as etapas serem validadas. Se todas as etapas forem aprovadas, o status final da execução será Aprovado. * **Rejeitado:** quando este status for selecionado dentro das regras, se qualquer uma das regras dentro de uma etapa for rejeitada, o workflow só poderá prosseguir com as validações nas próximas etapas se houver uma condição Rejeitado. Caso contrário, o status final da execução já seria Rejeitado. No entanto, com a condição em vigor, o status final da execução dependerá das validações nas outras etapas. * **Pendente:** em casos em que uma regra é definida com status Pendente e fica pendente, essa etapa específica aguardará uma ação manual para determinar seu status final e continuar o fluxo definido. Essa ação manual é Aprovar ou Rejeitar a regra, não a execução inteira. Após essa ação, as etapas subsequentes serão executadas se houver uma sequência no fluxo. O status final da execução só será determinado após todas as etapas serem validadas. * **Alerta:** se este status for selecionado, um evento/alerta será disparado pela Trust Platform, indicando que é necessária atenção para esta execução. Diferentemente do status Pendente, isso não interromperá o fluxo; ele continuará realizando consultas e validações nos serviços. As próximas etapas poderão ser validadas com base em suas condicionais configuradas, seja Aprovado ou Rejeitado. Se todas as etapas aprovarem, o status final da execução será Aprovado. Se qualquer etapa rejeitar, o status final será Rejeitado, independentemente da regra de Alerta. * Observação: não será possível alterar o status desta regra. ### Configurações do workflow Ainda na tela do Workflow Builder, algumas configurações podem ser feitas. Você tem a opção de associar um Onboarding Template a este workflow específico, se isso estiver alinhado com a necessidade do cliente. Fazendo isso, ao criar links de onboarding para serem enviados aos usuários finais, as etapas e o layout do onboarding corresponderão às necessidades e à identidade visual do cliente. {% hint style="warning" %} **Importante:** se nenhum Onboarding Template estiver associado ao Workflow, os links de onboarding criados usarão o template padrão da CAF. Isso significa que será aplicado um fluxo inicial básico com a identidade visual da Caf. {% endhint %} Outra configuração que pode ser definida na mesma tela é o webhook. Na aba de configurações, você pode editar o campo Webhook se desejar receber notificações sempre que uma transação for concluída ou entrar em status pendente. Lembre-se de que qualquer alteração feita exige que o usuário clique no botão salvar no Workflow Builder para que as edições tenham efeito. Após essa ação, todas as consultas vinculadas a este workflow serão प्रभावितadas. Na tela inicial de listagem do Workflow Builder, além de haver uma lista de todos os workflows criados, você também pode excluir qualquer um deles por ali ou clicar para editar. Clique nos três pontos de um workflow para realizar essa ação. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.caf.io/caf-docs/caf-product-guides-pt-br/guia-do-usuario/trust-platform/workflow-builder.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.