Valia × RD — Identidade + Automações (API)

Objetivo: validar políticas de resolução (CPF + FSS) e desenho de automações (ciclo mensal, estado civil) antes de implementar o middleware em produção. Não altera webhook intranet nem base operacional da Priscila.

Automações E e F dependem de API Valia → middleware (cf_data_de_admissao, estado civil, dependente). Cenários A–D são pré-requisito de identidade; E/F modelam jornadas no RD após resolução.

CPF = pessoa FSS = contrato/plano Email = chave técnica RD (não chave de negócio)

API Valia → Middleware M2BR → RD Station (eventos + workflows)

Produção atual (webhook → intranet) permanece separada — fora deste escopo

Bloco 1 — Identidade (duplicados)

Bloco 2 — Automações e API

Riscos fixos (callouts)

RD não permite dois contatos com o mesmo e-mail.
Cenário A sem consolidação = fragmentação (2 leads).
Campo cf_fss no perfil pode refletir só o último plano ativo.
Ciclo mensal (E) exige campo derivado ou tag — não basta “últimos 30 dias de admissão”.
Estado civil (F) sem middleware dispara campanha errada para todos casados.
Paridade Responsys depende de documentação Bruno (pendente).
Envio real para e-mail do titular (B) = Fase M8, fora do núcleo.

Valia × RD Station — Identidade + automações (API Valia → RD)

Mesmo CPF, e-mails diferentes

E-mail do titular no dependente

Mesmo e-mail, vários FSS

Comunicação só do plano X

Ciclo mensal (dias 1–5)

Estado civil → upgrade + dependente

Fluxos de automação

Matriz de colisões

Fases do middleware

Riscos fixos (callouts)