Como funciona o MULTICASE

Antes de tudo:

Imagine uma linha principal de conversa (o script jornada). Em certos momentos, em vez de seguir só essa linha, você pode abrir outros roteiros — por exemplo, um texto só para quem escolheu “cartão” e outro só para “empréstimo”. O Multi Case existe para isso: um convite pode carregar a jornada e vários roteiros auxiliares (casos), e o sistema decide qual trecho faz sentido naquele atendimento.

• O que o usuário final percebe: uma conversa guiada; em alguns pontos o conteúdo pode mudar conforme dados da proposta ou do cliente.
• O que a empresa configura uma vez (no script): mensagens, transições entre mensagens e, onde precisar, caminhos alternativos (alternativePaths) com ou sem condições.
• O que muda a cada convite: quais roteiros entram naquele link (script.cases), valores de variáveis (fields) e dados do cliente — é isso que personaliza a experiência sem reescrever o roteiro inteiro.

Analogia: a jornada é a trilha principal; os casos são blocos de conteúdo que só entram quando o convite e as regras permitem.

Mini-glossário

O que é Multi Case (conceito)

O Multi Case permite que a partir de uma mensagem da jornada o sistema redirecione o fluxo para mensagens de outros scripts. Isso se liga em dois lugares:

1. Na criação do script: em uma message transition, o campo alternativePaths indica que, saindo da mensagem pai (parentId), o motor pode considerar entradas em outros roteiros antes de seguir para a mensagem destino (messageId), conforme as regras.
2. Na criação do convite multicase: você informa a jornada (script.journey) e a lista de casos (script.cases) — cada item aponta para um scriptReference e traz fields usados nas condições e nos textos.

Sem o convite multicase, os “outros scripts” não estão disponíveis naquela sessão da forma descrita aqui.

Como Script e Convite se encaixam

Lembrete: o roteiro diz em que ponto pode haver desvio; o convite diz quais roteiros e quais valores entram naquela sessão.

Nomes nos scripts vs nomes no JSON do convite (importante)

Nas condições do script, o campo path usa textos fixos do tipo invite.scripts.fields... e invite.customer.fields.... No JSON real do convite, os valores vêm de outras chaves. Use a tabela abaixo para não misturar.

Erro comum: copiar o texto invite.scripts.fields para o JSON do convite. No payload, use script.journey e script.cases como na documentação da API.

Fluxo do usuário (visão geral)

O que este desenho mostra: o cliente entra pela jornada; num ponto com alternativePaths, o sistema avalia regras e/ou percorre os casos do convite; depois a linha pode continuar na jornada (próxima mensagem).

Na transição, quando há condições, o motor compara path, operator e value com os dados do convite. Quando não há lista de conditions, o comportamento é outro (veja a próxima seção).

Convite multicase: o que enviar e o que pode dar erro

Endpoint (referência): criação de convite multicase na API pública da NuVidio (veja Links oficiais). Base de exemplo: https://apigw.nuvidio.com/video-agreement.

Lembrete: no schema público, expiresAt é obrigatório no corpo da criação; customer costuma exigir cpf e fields (com label e value em cada item). Confira a referência OpenAPI para o contrato exato.

Datas

Use ISO 8601 com milissegundos, no formato:

YYYY-MM-DDTHH:mm:ss.SSS

Exemplo de parte da data: 2025-03-29 (ano-mês-dia), depois T, depois hora 17:21:00.000.

Campos script.journey.fields (jornada)

• Toda variável usada nas mensagens da jornada precisa ter valor coberto aqui (labels/values correspondentes). Se faltar, a criação do convite pode falhar.
• CPF nas mensagens: recomenda-se formato legível para leitura por IA, por exemplo 111.222.333-44.

Campos script.cases[].fields (cada caso)

• Se uma variável aparece no script do caso e não veio em script.cases[].fields, o sistema tenta usar o valor em script.journey.fields.
• Se ainda assim não houver valor, a criação do convite pode falhar.

Resposta de sucesso (resumo)

Em caso de sucesso (201), você recebe dados como inviteId, inviteUrl, janelas availableAt / expiresAt e outras URLs úteis ao fluxo. O detalhe completo dos campos está na referência OpenAPI oficial.

Condicionais: com e sem conditions

As condições só se aplicam ao modelo em que customerJourneyType do script é agreement (conforme regras atuais da plataforma).

Modo multicase

Informar alternativePaths na transição ativa o script em modo multicase naquele ponto: a partir da mensagem pai, o fluxo pode ir para mensagens de outros scripts que você associou ao convite multicase.

Sem lista de conditions

Se existir alternativePaths mas não houver condições configuradas, o fluxo segue para todas as mensagens dos scripts informados em script.cases, na ordem em que os casos aparecem no convite.

Com lista de conditions

Cada item costuma ter:

• path: onde buscar o valor (veja tabela de paths na próxima subseção).
• operator: como comparar (veja tabela de operadores).
• value: valor esperado na comparação (quando o operador exige).
• scriptReference: para qual roteiro ir se a condição for atendida. Se você omitir scriptReference, o sistema pode seguir para todos os caminhos (scripts) possíveis desde que a condição seja alcançada.

Paths permitidos em path

Operadores (referência rápida)

Exemplo mínimo: condição em campo de script (product)

Propósito: no roteiro, ao ir da mensagem A para a B, se o campo de script product for “empréstimo”, desviar para o roteiro referenciado.

Trecho da criação do script (transição):

{
  "parentId": "mensagem A",
  "messageId": "mensagem B",
  "alternativePaths": {
    "conditions": [
      {
        "path": "invite.scripts.fields.product",
        "operator": "equal",
        "value": "empréstimo",
        "scriptReference": "script_emprestimo"
      }
    ]
  }
}

Propósito do convite: enviar product (e demais variáveis necessárias) em script.journey.fields e/ou nos fields de cada item de script.cases, de forma consistente com o que as mensagens e condições esperam.

Exemplo mínimo: condição em campo do cliente (age)

Propósito: desviar para um roteiro se a idade do cliente for maior que 30.

Trecho da criação do script:

{
  "parentId": "mensagem A",
  "messageId": "mensagem B",
  "alternativePaths": {
    "conditions": [
      {
        "path": "invite.customer.fields.age",
        "operator": "greater",
        "value": "30",
        "scriptReference": "script_emprestimo"
      }
    ]
  }
}

Propósito do convite: incluir em customer.fields um item com label age e o value desejado (ex.: "35").

Gatilho de interrupção

Em uma frase

Quando o cliente está numa jornada multicase e já saiu do script inicial, se a resposta de voz/texto não for a esperada para o nó atual, o backend pode interromper o fluxo normal e buscar uma mensagem de tratamento ou fallback configurada na lógica multicase — em vez de seguir a transição “feliz”.

Onde isso aparece na API

• Endpoint de recuperação de script do cliente (veja Recuperar script cliente nos links oficiais).
• Só faz sentido em fluxo multicase. A interrupção descrita aqui não se aplica da mesma forma quando o tipo atual é script de caso (ScriptCase): nesse caso a interrupção deste modelo fica desabilitada e vale o comportamento padrão do caso.

Quem decide se a resposta “bate” com o esperado

Nossa I.A compara o que o cliente disse com a lista expectedResponses da mensage. Se não bater, o cliente envia isExpectedAnswer: false no payload da requisição de recuperação de script.

Lembrete: se isExpectedAnswer não vier (ausente), o sistema não trata como interrupção por esse mecanismo; o fluxo segue o padrão.

Cenários (tabela)

Resposta afirmativa após interrupção

Em uma frase

Depois que um fluxo em script filho é interrompido (por resposta fora do esperado), o sistema pode avaliar a próxima entrada usando o path invite.customer.affirmative_answer. Assim você direciona o cliente para outro roteiro conforme a resposta foi tratada como afirmativa ou não (valores true ou false em string, conforme operador equal).

Quem valida a fala do usuário nesse contexto é o fluxo com Pipecat, alinhado ao front-end.

Exemplo mínimo na transição (condição)

Propósito: após a lógica de interrupção, se a resposta afirmativa for equivalente a “false”, seguir para o roteiro script_emprestimo.

{
  "parentId": "mensagem A",
  "messageId": "mensagem B",
  "alternativePaths": {
    "conditions": [
      {
        "path": "invite.customer.affirmative_answer",
        "operator": "equal",
        "value": "false",
        "scriptReference": "script_emprestimo"
      }
    ]
  }
}

O convite multicase deve listar os casos (script.cases) com os scriptReference e fields coerentes com os roteiros que podem entrar após essa decisão.

Links oficiais

• Criar script
• Criar invite multicase