Entenda nossa jornada desde o início

Esta página explica o ClickFlow para quem vai usar a jornada ou integrar com ela. O contrato de cada chamada fica nas páginas ligadas ao final.

O ClickFlow em uma frase

O ClickFlow conduz o contato por uma formalização em sequência: coletar dados, confirmar a identidade, avaliar risco, registrar um aceite ou uma notificação e assinar. Sua empresa desenha essa jornada uma vez. Cada pessoa gera uma execução.

Uma analogia

Pense num restaurante com a cozinha organizada.

• A receita é o flow: a lista de etapas, na ordem, escrita uma vez e reaproveitada.
• O chef lê a receita e diz qual é o próximo passo. Ele não cozinha e não leva o prato à mesa. No ClickFlow, é o Orquestrador.
• O garçom pergunta o que servir agora, busca na cozinha certa e entrega pelo caminho combinado. No ClickFlow, é o Executor.
• As cozinhas fazem cada prato com autonomia. No ClickFlow, são os módulos.

O que muda na operação

Contratar crédito, admitir alguém ou cadastrar um cliente costuma juntar ferramentas soltas. O contato recebe links de remetentes diferentes, e a empresa perde de vista em qual etapa a transação parou.

Com o ClickFlow, a jornada é uma só. Cada módulo continua especialista. A esteira cuida da ordem, do estado e da entrega no canal escolhido no disparo.

A composição é livre dentro do que os módulos permitem. Um flow pode ser só uma coleta. Outro pode ir da coleta à assinatura.

Vocabulário para ler o resto

Quem faz o quê

Três papéis, com fronteira fixa.

Orquestrador. Guarda a definição do flow e o estado de cada execução. A cada momento responde qual é a próxima etapa. Não envia mensagem e não executa o módulo.

Executor. Recebe o disparo, pergunta ao Orquestrador o que fazer, aciona o módulo e entrega a etapa no canal. Não escolhe a ordem da jornada.

Módulos. Executam a capacidade da etapa: coletar, verificar, avaliar risco, registrar aceite ou notificação, colher a assinatura. O ClickFlow os coordena. As regras internas de cada módulo continuam no próprio módulo.

O flow é linear. A lista de etapas tem uma ordem e a execução a percorre do começo ao fim. Não há desvio condicional para um caminho alternativo. Quando uma etapa encerra a jornada, a execução termina. Ela não salta para outro ramo.

O que entra numa etapa

O flow usa só as etapas daquele caso. Consulte o schema de cada step no Orquestrador e o comportamento de cada capacidade em Módulos.

acceptance não é módulo. É uma confirmação de leitura: uma mensagem no WhatsApp com botão para seguir. Serve para o contato avançar. O aceite de um termo, com registro da decisão, é consent. Os dois convivem.

Autenticação

O verify tem três tipos:

• Prova de vida (liveness). Confirma que há uma pessoa presente. O resultado é aprovado ou reprovado.
• Biometria comportamental (biometric_behavior). Compara o rosto e produz o sinal de fraude que o KYC consome.
• Biometria de base ampliada (identity_biometrics). Compara o rosto. No inconclusivo, devolve uma nota de risco. Não alimenta o KYC.

No padrão, a reprovação encerra a execução, sem nova tentativa na mesma execução. Com result_policy: "passthrough", a etapa fica marcada como falha e a execução segue. Esse é o caminho usado quando o KYC dá a palavra final. Um resultado inconclusivo não encerra a jornada.

passthrough cobre a reprovação, que é um resultado válido. Uma falha operacional do fornecedor, sem resultado utilizável, encerra a etapa e a execução.

A verificação da esteira e o requisito de autenticação do envelope são independentes. Aprovar um não libera o outro.

Quando o tipo aceita mais de um fornecedor, provider_priority declara a ordem de tentativa. A lista de tipos e fornecedores está em Módulos.

KYC

O Módulo de KYC avalia pessoa física (CPF). Um verify com biometric_behavior e result_policy: "passthrough" precisa precedê-lo. Sem o passthrough, a reprovação da biometria encerra a execução antes da avaliação. liveness e identity_biometrics não precedem o KYC.

Aprovado, a jornada segue. Reprovado, a execução termina. A régua de risco é do módulo. O flow não escolhe um caminho alternativo depois da resposta.

Aceite e notificação

consent aponta para um template. O template diz se a etapa registra uma decisão (aceitar ou recusar) ou comunica o contato. As variáveis da mensagem podem ser preenchidas no disparo. O aceite não gera PDF: o desfecho é status da etapa.

Assinatura

Há duas experiências.

• signature. O contato assina no fluxo de assinatura da Clicksign. Signatários extras, ordem e configurações do envelope entram no passo. A identidade de um signatário pode vir de um campo de form anterior.
• embedded_signature. O documento aparece e é assinado dentro da jornada. Nesta versão, só o contato da execução assina. A Clicksign não envia WhatsApp nem e-mail com o link deste passo. Quem conduz o contato até o link é a esteira, no canal do disparo.

O documento da assinatura pode ser um modelo, um arquivo já guardado ou um arquivo enviado no disparo. Dados coletados num form podem preencher esse documento. Arquivos anexados no formulário ficam na execução, para consulta. Eles não entram sozinhos no documento assinado.

Só a assinatura concluída faz a jornada avançar. Recusa, vencimento e cancelamento do envelope deixam a execução em aberto. Assinatura presencial não é suportada.

Como a esteira é montada

O flow é um nome e uma lista ordenada de etapas, criado pela API do Orquestrador. Não há construtor visual: a definição vai no JSON.

Antes de disparar, o que a etapa referencia precisa existir. Um form aponta para uma versão de formulário já publicada no Módulo de Coleta de Dados (ClickForm). Uma assinatura aponta para um modelo, um arquivo já guardado ou um arquivo que viaja no disparo. Um consent ou um acceptance aponta para um template aprovado.

O flow tem quatro status:

Publicar congela a definição para quem já entrou. Uma execução segue o flow do momento em que começou. Despublicar, editar e publicar de novo vale para os disparos seguintes.

Como uma execução começa

Disparar é pedir ao Executor: inicie este flow para este contato, neste canal.

No corpo vão o channel, os dados do contato e, quando fizer sentido, um contexto com o que a empresa já sabe (para pré-preencher um formulário, compor o documento ou preencher variáveis de mensagem) e os arquivos da assinatura.

A resposta traz o identificador da execução. Com ele, o sistema consulta o status a qualquer momento. Consulte o corpo completo do POST /execute no Executor.

O e-mail do contato é um dado opcional. Ele não é canal de entrega da jornada.

Os três canais

O canal não é etapa. A definição do flow não guarda canal. A escolha acontece no disparo, e o mesmo flow pode ser disparado por canais diferentes.

web e api são canais diferentes. Em web, a Clicksign entrega a página que conduz a jornada. Em api, a Clicksign não envia mensagem: o sistema da empresa apresenta cada link. Veja os campos e respostas de cada canal em Executor.

A etapa acceptance sempre acontece no WhatsApp, mesmo quando o disparo foi web ou api. Sem telefone, essa etapa falha.

Uma execução, do começo ao fim

Exemplo: crédito no WhatsApp, com quatro etapas — coleta, biometria comportamental com passthrough, KYC e assinatura.

1. O sistema da empresa chama o Executor com os dados de Maria da Silva e channel: "whatsapp".
2. O Executor pede ao Orquestrador para abrir a execução. A definição daquele instante fica associada a ela. A primeira etapa é a coleta.
3. Maria recebe a mensagem de apresentação e o link do formulário. Nome e documento podem chegar preenchidos.
4. O módulo avisa que a etapa terminou. O Executor pergunta de novo. A próxima etapa é a biometria.
5. Maria faz a selfie. Com passthrough, uma reprovação marca a etapa como falha e a jornada segue, para o KYC decidir. Sem passthrough, a reprovação encerraria a execução aqui.
6. O KYC roda sem tela para Maria. Aprovado, a jornada segue. Reprovado, a execução termina.
7. O envelope é criado com o documento preenchido pelos dados da coleta. Anexos do formulário não entram nesse documento. Maria assina. A etapa só conclui com a assinatura feita.
8. Não há próxima etapa. A execução fica concluída.

Enquanto isso, o sistema consulta a execução e vê a etapa atual, as respostas, o resultado de cada verificação e os documentos.

Status da execução

Cancelar é uma decisão da empresa sobre aquela execução. Reprovação de biometria, recusa de aceite e reprovação de KYC são desfechos da jornada. Cancelar a execução não cancela o envelope na API de Assinatura.

Quando a jornada para, segue ou falha

Três situações diferentes, para o integrador não tratar tudo como erro técnico.

A etapa encerra a execução. Reprovação do verify no padrão. KYC reprovado. Falha operacional do fornecedor de identidade, inclusive quando a etapa está em passthrough. acceptance sem telefone.

A etapa não encerra a execução. Resultado inconclusivo do verify. Reprovação do verify com passthrough: a etapa fica falha e a próxima começa. Recusa, vencimento ou cancelamento do envelope: hoje a execução não é encerrada por esses eventos e só avança com a assinatura concluída.

A empresa cancela. O status vai para canceled e a execução não retoma.

O formato de cada erro e o código de cada falha estão no Orquestrador e no Executor. Esta página não repete esses contratos.

Seis combinações comuns

O contrato de cada etapa está no Orquestrador. Os exemplos mostram a ordem, não o payload.

1. Proposta. Coleta dos dados da proposta, nova coleta com quem vai assinar, assinatura do documento gerado a partir do modelo.
2. Crédito. Coleta, biometric_behavior com passthrough, KYC e assinatura do contrato preenchido com os dados coletados.
3. Cadastro de parceiro. Coleta, liveness do responsável e assinatura do contrato. Documentos enviados no formulário voltam na consulta da execução.
4. Aceite ou aviso. Uma etapa consent. O template registra o aceite de um termo ou envia a notificação, com as variáveis preenchidas no disparo.
5. Admissão com testemunha. Coleta, liveness e signature com signatários extras e ordem de assinatura.
6. Atualização cadastral. Só a coleta. Os dados validados voltam para o sistema da empresa, sem documento.

Acompanhar no Cockpit

O Cockpit é a tela em que o operador da empresa vê as execuções: qual flow, qual contato e em qual etapa cada uma está. Ele lê o estado que o Orquestrador já guarda.

A definição da esteira continua na API. O Cockpit não desenha o flow e não substitui a consulta por execution_id quando o sistema precisa do dado estruturado.

Limites atuais

Estes limites são do produto hoje. Trate-os como regra de integração, não como detalhe temporário a contornar no payload.

• O flow é linear. Não há ramo condicional.
• Flow publicado não é editável. Para mudar, despublique, edite e publique de novo.
• Quem já está numa execução segue a definição do início.
• Cancelar uma execução é definitivo.
• Não há construtor visual.
• acceptance sempre usa WhatsApp e exige telefone.
• O KYC de pessoa física depende de um verify com biometric_behavior e passthrough que o preceda.
• Só a assinatura concluída avança a etapa de assinatura. Recusa, vencimento e cancelamento do envelope não encerram a execução.
• Assinatura presencial não é suportada.
• Em embedded_signature, só o contato da execução assina.
• Anexos do formulário não entram automaticamente no documento assinado.
• Cancelar a execução não cancela o envelope.

Segurança da integração

Orquestrador e Executor autenticam com o access token da conta no header Authorization, sem o prefixo Bearer. Sandbox e produção usam hosts e tokens do próprio ambiente. Documento assinado em sandbox não tem validade jurídica.

O disparo carrega dados do contato. Envie o que a jornada precisa para preencher, verificar e assinar. O token da API fica no sistema da empresa. Ele não vai no link que o contato abre.

A verificação feita na esteira não altera o requisito de autenticação configurado no envelope, e o contrário também vale.

Para obter o access token, veja Access token. Os hosts estão em Informações gerais. O passo a passo da integração está em Primeiros passos.

Perguntas frequentes

O ClickFlow substitui a assinatura eletrônica?
A assinatura entra como uma etapa, pelos identificadores signature ou embedded_signature. Antes dela, a esteira pode coletar, verificar, avaliar risco e registrar aceite.

Preciso usar todos os módulos?
O flow leva só as etapas daquele caso.

O contato precisa baixar um aplicativo da Clicksign?
No WhatsApp, as etapas abrem no próprio aplicativo de mensagem. Na Web, a jornada é uma página. Na API, ela acontece no aplicativo ou portal da empresa.

Como a esteira é criada?
Pela API do Orquestrador, em JSON. O passo a passo está em Primeiros passos.

Dá para alterar um flow que já está publicado?
Despublique, edite e publique de novo. Quem já estava numa execução segue a definição com a qual começou.

Se a biometria reprovar, o contato tenta de novo na mesma execução?
A reprovação encerra a jornada, salvo quando a etapa está com passthrough. Uma nova tentativa é uma nova execução.

Onde vejo em qual etapa o contato parou?
Na consulta da execução, pelo Executor ou pelo Orquestrador, e na lista do Cockpit. Cada etapa tem o próprio status.

Qual a diferença entre consent e acceptance?
consent é a etapa do Módulo de Aceite e do Módulo de Notificação. acceptance é a confirmação de leitura no WhatsApp e exige telefone em qualquer canal de disparo.

Posso testar antes de produção?
O sandbox está liberado para a integração. Produção é liberada para quem contratou o ClickFlow. O aviso está na Introdução ao ClickFlow.

Glossário

Próximo passo ➡️

• Primeiros passos — autentique a integração e execute o primeiro flow.
• Orquestrador — crie, publique e consulte o flow.
• Executor — dispare a execução e escolha o canal.
• Módulos — o que cada etapa faz e quais regras mudam o desfecho.
• Webhooks — avisos dos módulos ao longo da jornada.