F Estado civil → upgrade + dependente

SOLTEIRO → CASADO · oferta plano · parceiro dependente · ST-08

0 1 2 3 4 5 6

T0 — Contexto

Participante passa de SOLTEIRO para CASADO. Valia envia e-mail oferecendo upgrade de plano e inclusão do parceiro como dependente.

Gatilho por evento (mudança pontual), não workflow mensal — ver mapa de fluxos.

Valia T1 — Payload API

{ "cpf": "55555555555", "fss": "FSS-SMOKE-F-001", "estado_civil_anterior": "SOLTEIRO", "estado_civil_novo": "CASADO", "elegivel_upgrade": true, "dependente": { "cpf": "66666666666", "nome": "Parceiro(a)", "email": "titular@smoke…" } }

RD T2 — Sem middleware

Atualizar só cf_estado_civil = CASADO no perfil dispara campanha para todos casados — sem elegibilidade nem upgrade.

Dependente com e-mail do titular: colisão EMAIL_ALREADY_IN_USE (cenário B).

MW T3 — RULE_ESTADO_CIVIL_UPGRADE

  • Identity OK (A–D) → email canônico do titular
  • Evento mudanca_estado_civil + cf_fss + cf_estado_civil_novo
  • Se elegivel_upgrade e cf_plano ∈ lista acordada → tag elegivel:upgrade-casamento
  • Se dependente: RULE_B_ALIAS_EMAIL + evento opcional inclusao_dependente

RD T4 — Automação RD

Gatilho: conversão mudanca_estado_civil Condições: cf_estado_civil_novo = CASADO cf_plano IN (PREVALER, VALIAPREV, …) tag contém elegivel:upgrade-casamento Ação: email "Upgrade plano + dependente"
ST-04/04b já validaram evento + campo estado civil na API.

T5 — Ligação com cenário B

Se o parceiro usa o mesmo e-mail do titular, o middleware cria contato com alias {cpf}@smoke… e guarda email_real em bio.

Abrir cenário B (titular / dependente) →

T6 — Decisão workshop

Pergunta Bruno: API envia dependente no mesmo payload da mudança civil?