Status do Projeto: o que você precisa ter na ponta da língua
Sprint 1 encerrada (08 a 11/SET): 6 de 7 histórias, cascas Gov.br dos três portais e esteira CI/CD. Sprint 2 (14 a 18/SET) está em curso com Squad 1 (NTT Data + Nespon) e dois TCs MuleSoft. O que trava o 15/NOV agora é autenticação, APIs e o modelo canônico. Comitê Executivo hoje às 15h. Apresentação para o time de Sales amanhã, 16/SET.
📐 Linha de base (em revisão contínua) melhor leitura em 12/SET
Tudo abaixo continua sendo ponto de partida, não versão final. Escopo, estimativas, marcos e desenho de integração são revisitados a cada sprint. Qualquer número (pontos, datas, quantidade de APIs) é a melhor leitura possível em 12/SET, no Status Report de fechamento da Sprint 1.
🏗️ Arquitetura da oficina: o desenho que saiu de Florianópolis Baseline 04/SET
Este é o diagrama oficial enviado ao cliente no Status Report externo. Material em definição, mas já é a melhor leitura conjunta DTP × Salesforce. A leitura camada a camada e as tensões com a Sprint 0 estão na Parte 4 (seções 4.7 e 4.8).
Fonte: [MARKETPLACE PAT] Arquitetura da Solução_20260904.pdf, enviado por Rafael Roquette no Status Report de fechamento da oficina (04/09/2026).
| Camada | O que a oficina fechou |
|---|---|
| Personas | J01 Beneficiária (gov.br Prata/Ouro) · J02 Facilitadoras (~600, certificado digital CNPJ via API) · J03 Estabelecimento (~1M, gov.br Prata/Ouro) · J04 MTE Fiscal/Gestor (SSO institucional / GERID) · J05 Adquirente |
| Experiência | Experience Cloud / LWR. Design System gov.br, e-MAG 3.1 / WCAG 2.1 AA. Cascas já navegáveis na Sprint 1: Beneficiária, Estabelecimento e Portal de Gestão do PAT (antigo console MTE). Time de Experience entra em 21/SET (Sprint 3) para menu e Libras. |
| Salesforce Core | Shield com Platform Encryption + Field Audit Trail. Módulos: Cotação e Contratação (seleção manual), Folha e Financeiro (boleto/NF), Credenciamento (ATIVO / INATIVO / CANCELADO / banido), Monitoramento a posteriori (até 30M transações/dia), Config MTE (CNAEs, regras, trilho de pagamento). |
| MuleSoft on-prem | Porta de entrada única (soberania). Marketplace↔Mule em HTTPS. Transações operacionais em CSV/streaming para o Lakehouse (S3). Salesforce→DATAPREV em microbatch agora, broker depois. Acesso de pessoa (VPN/GlobalProtect + A3) é distinto da conectividade de sistema (mTLS na borda). CPF tokenizado. Dado sensível resolvido só no perímetro. |
| Externos (consumidos, não desenvolvidos) | Novo PAT / gov.br / GovID (procuração digital) · Receita Federal / SERPRO (CNPJ, CNAE) · eSocial e CTPS Digital (confronto de folha e notificação). Nuclea confirmada fora: PAT hoje não está no SPB nem no registro/liquidação de recebíveis. O projeto não registra, não liquida e não se conecta à Núclea no MVP de 15/NOV. |
| Carga inicial | Marco 18/10: staging, qualidade mínima, dedup por CNPJ, reconciliação. |
| Analítica DTP | No Go Live de 15/NOV, o painel totalizador (contratos, credenciadas e facilitadoras ativas) é entrega do projeto. Análise aprofundada (risco, cruzamentos) fica com o SUDA (Rafael Tabosa). Acesso individual governado pelo ADM da org. Time de Analytics Salesforce a partir de 19/OUT. |
🪪 O que a Community Login deixa (e o que não deixa) no portal ADR-001 · 16/SET
Imagine o portal do estabelecimento como um balcão. A licença que o PAT já comprou, Customer Community Login, entrega o crachá de quem entra: a pessoa lê e edita a empresa. Esse crachá não cria empresa nova. Criar Account só existe na família Plus, que custa por usuário e não está no recorte comercial atual.
Quando o time ligou o auto-cadastro, o representante não criava o estabelecimento e também não via os que já existiam. A plataforma recusava o INSERT em Account. Isso apareceu na POC (pat-dev), não só no papel.
| Família de licença | Tipo de site | O que faz com Account |
|---|---|---|
| Commerce Portals | B2C | Lê e edita |
| Customer Community (Login) | B2C. É a desta org. | Lê e edita. Não cria. |
| Customer Community Plus | B2B | Lê, cria e edita |
Fonte: tabela de SKU anexada por Eric Gasparotto em 16/09/2026, alinhada à documentação Salesforce de User License Types for Experience Cloud Sites. Commerce Portals e Community Login tratam Account igual neste recorte. Só Plus cria.
O que o comercial confirma
Que a SKU contratada é Customer Community Login, não Plus. Sem isso o ADR fica em rascunho.
O que a arquitetura fecha
Se um representante cuida de vários estabelecimentos (1:N) ou se a relação é N:N. Isso muda o Sharing Set.
O padrão daqui para frente
Toda gravação nova no portal passa por essa camada de servidor. Gravar no contexto do usuário do portal volta a falhar.
Eric Gasparotto, 16/09/2026, canal dataprev-petit-committee. ADR-001 (draft): Padrão de acesso a Account sob licença Customer Community Login. Opções descartadas: upgrade para Plus (custo por usuário) e objetos custom (sai do modelo canônico). Salesforce Help, User License Types for Experience Cloud Sites.
🔔 O que não pode esperar: decisões em aberto e próximas ações 15/SET
A Sprint 1 entregou fundação. A Sprint 2 ataca o que trava o 15/NOV. O que resta abaixo ainda trava prazo, integração, folha ou o baseline de licenças desta org.
Prioridade máxima da Sprint 2. Felipe Vinturini e 2 TCs precisam de VPN/GlobalProtect, certificado A3 com e-mail corporativo, Git, logs e perfil de administração do Mule. Formalizar a lista em 15/SET. Sem isso a sprint de integrações não anda de verdade. Ugo Cavalcanti (DTP) já se ofereceu no Slack para resolver a VPN. Plano B da DTP: acompanhamento presencial se precisar. Governança/gestor da plataforma Mule continua indefinido, mas isso é tema de sustentação e não pode segurar o acesso de desenvolvimento.
A empresa envia o arquivo da competência. A facilitadora puxa e gera o boleto. Processamento e notificação na CTPS só depois da confirmação de boleto pago. Isso destrava a arquitetura da Sprint 3. O detalhe continua na seção 4.8 e no Backbone de licenças.
O fluxo começa no Novo PAT. Gov.br autentica a pessoa; o papel (beneficiária, estabelecimento, gestor) tende a vir do Novo PAT, não do gov.br. Diogo sugeriu SAML IdP-initiated + JIT; André Gomes lembrou o roteiro oficial OIDC (Authorization Code + PKCE). Eric: o foco não pode partir do gov.br isolado, porque o gov.br afeta a entrada no Novo PAT. Diogo também sugeriu usar o portal de origem como pacote de permissão (um ator por portal). Raimundo (MTE) ainda não acessa o Slack. GERID/CoffeeBean envolve o time do Márcio Gomes.
A org do marketplace já existe, está em desenvolvimento e é distinta da org Dataprev. A leitura está no Backbone de licenças: quem loga, o que já foi contratado e o que o volume de vale não pede à plataforma. Essa leitura alimenta a análise do contrato ilimitado. O ateste DTP de processamento fora do Brasil continua na frente de Agentforce.
O ADR-001 pede confirmação comercial de que a licença é Customer Community Login, não Plus. Sem Plus, o portal não cria Account no contexto do usuário. O contorno (LWC + Apex em System Mode + Sharing Set) já está validado em pat-dev. O card desta seção traz a decisão completa, as opções descartadas e o que ainda falta fechar (cardinalidade 1:N ou N:N).
Jaime cobrou o MVP de cotação no Comitê. Célula de desenvolvimento entrou em 14/SET. Cotação e contratação pesam nas Sprints 2 e 3. UX/UI entra em 21/SET. Carga/migração de estabelecimentos subiu da Sprint 9 para a 3 ou 4: cerca de 300 arquivos sem padrão, CNPJ alfanumérico, 60 dias de recadastro. Raimundo manda exemplos (grandes e pequenas) até 18/SET.
Salesforce atua como cliente da CTPS, não como fornecedor. Marina e Georges agendam; arquitetos na pauta. Sem isso a notificação ao trabalhador não tem trilha.
Presencial já está combinado. Brasília vs João Pessoa ainda aberto com o cliente. Homologação 06 a 15/NOV. Pronto interno 06/NOV. Go Live 15/NOV. Operação assistida até 18/DEZ.
Canal #dtp-marketplace-pat-equipe-projeto já está no ar no Salesforce External (criado em 08/SET). Backlog, canvas, diagramas e APIs no mesmo lugar. Cortesia no workspace DTP segue pendente (Jackson / Fernanda Pacheco / Fernanda Souza adm). Raimundo ainda sem acesso. Histórico migra junto quando a cortesia sair.
Na arquitetura de 11/SET a DTP abriu espaço para POC de agente informacional no portal. Em paralelo, conversa interna (15/SET) sobre POC no site do MTE para substituir o Celeste. Ainda frio, mas esquentando. Web primeiro. WhatsApp transacional só depois da soberania. Não puxar agora.
Data Cloud sem movimento que justifique Fase 1. Marketing Cloud: Diogo já adiantou casca de notificações (visualização/histórico), mocada, prioridade baixa na Sprint 2. Fase 1 continua sininho + e-mail, e poucos.
Fontes: Status Report Semanal Interno e Externo, Rafael Roquette, 12/09/2026; Ata do Comitê Executivo, 08/09/2026; deck [MARKETPLACE PAT] Comitê Executivo_20260915; canal Slack #dtp-marketplace-pat-equipe-projeto (14 e 15/SET); Granola “Funcionamento do Marketplace atual” (14/SET).
🌱 Pipeline de oportunidades Status Report 12/09
Leitura atualizada do Status Report interno de 12/SET, cruzada com o Slack da Sprint 2. O que anda, o que é semente, o que está em atenção e o que ainda não vale forçar.
💬 Slack Anda
Canal #dtp-marketplace-pat-equipe-projeto no ar no Salesforce External desde 08/SET (backlog, canvas, diagramas, APIs). Squad 1 (NTT Data + Nespon) já dentro. Cortesia de 50 licenças no workspace DTP segue pendente. Raimundo (MTE) ainda sem acesso. Histórico migra junto.
Próximo: Jackson / Fernanda Pacheco / Fernanda Souza (adm) liberarem a cortesia e migrar o canal.
🤖 Agentforce Semente
DTP abriu espaço para POC de agente informacional no portal (11/SET). Em 15/SET surgiu a conversa de POC no site do MTE para substituir o Celeste (ainda fria). Sem série de atendimentos. A régua, se avançar, é action e conversa, não login. Web primeiro. WhatsApp depois, porque puxa soberania.
Próximo: ateste de processamento fora do Brasil. O baseline de consumo desta org está no Backbone de licenças.
🔌 MuleSoft Acesso trava
Desenho amadureceu (porta única, CSV/streaming, microbatch). Dois TCs já alocados. O que trava é VPN/A3/Git/logs/admin até 16/SET. Gestor da plataforma ainda indefinido (sustentação, não Go Live). André Gomes, Felipe Pontes e Ugo Cavalcanti no circuito DTP.
Próximo: destravar acessos com Ugo/DGI e formalizar ponto de contato Salesforce/Microsoft/Tableau até 16/SET.
🛠️ Sustentação L2 pós-projeto Semente
Alinhamento estratégico no evento (Juliana Brites e Saulo/DTP). Há indicação de que a sustentação pós 18/DEZ, em nível 2, poderá ser feita por PS. Rafa avalia que é só a ponta das oportunidades que podem vir.
Próximo: conectar o modus operandi DTP ao suporte Salesforce (CSM + PS).
📊 Tableau Em atenção
Combinado no Comitê: no Go Live, o painel totalizador (contratos, credenciadas, facilitadoras ativas) é entrega do projeto. SUDA (Rafael Tabosa) fica com análise aprofundada. Acesso individual, governado pelo ADM. Analytics Salesforce entra em 19/OUT.
Próximo: desenhar o recorte totalizador vs SUDA e ativar as cadeiras já contratadas.
📣 Marketing Cloud Introduzir com calma
O tema entrou via notificações. Na Fase 1 a solução é sininho + e-mail, e poucos. Diogo já adiantou casca de notificações (mocada, prioridade baixa na Sprint 2).
Próximo: ir introduzindo o tema com Fernanda Pacheco, Renato Soti e Tony Tonete. Sem forçar.
☁️ Data Cloud Não forçar
Data Cloud sem movimento que justifique Fase 1. Transações vão para o Lakehouse DTP (CSV/streaming). Hamilton Oliveira em FYI.
Próximo: não abrir conversa comercial agora.
🤝 CSM Cliente pronto
Marina, Fabrício e Georges já receberam o contato do Rudi. A bola está com o CSM. Comitê pediu ponto de contato DTP para as trilhas Salesforce/Microsoft/Tableau até 16/SET (Wanderley).
Próximo: Rudi pinga esta semana. Wanderley cobra o ponto de contato da diretoria DTP.
🗓️ Como o projeto opera agora Ritos e reporting
Prefixo de agenda: [MARKETPLACE PAT]. Núcleo Salesforce nos ritos: Rafael (PM), Eric (Senior TA), Diogo (TA), Felipe Vinturini (TA MuleSoft) e Giselle (Senior SA, alocação a partir de 28/SET). Raimundo (MTE) entra na daily porque as entregas do MTE estão no caminho crítico. Canal operacional: #dtp-marketplace-pat-equipe-projeto.
| Rito | Quando | Série | Como opera agora (Sprint 2) |
|---|---|---|---|
| Sprint Planning | Segunda, 9h às 10h (1h) | 14/SET a 14/DEZ | Planning da Sprint 2 foi na segunda 14/SET, 9h, e abriu autenticação, APIs e modelo canônico. Próxima: 21/SET. |
| Daily + bloco técnico | Terça, quarta e quinta, 9h30 às 10h30 (1h) | 09/SET a 17/DEZ | 15 min de daily + 45 min técnicos. Raimundo (MTE) entra no rito. Arquitetura extra: 15/SET 13h30. Autenticação e VPN estão no bloco técnico desta semana. |
| Sprint Review | Sexta, 9h às 11h (2h) | 11/SET a 18/DEZ | Review da Sprint 1 (11/SET) mostrou as cascas dos três portais. Próxima: sexta 18/SET, 9h. Precisa de quem tem autoridade de aceite. |
| Comitê Executivo | Terça, 15h às 16h (1h) | 08/SET a 15/DEZ | Rito semanal de liderança. Primeiro: 08/SET. Hoje: 15/SET, 15h (deck já no Drive). Próximo: 22/SET. Sem time de execução. |
🧲 Mapa de Poder — quem decide, quem influencia, quem pode bloquear Relacionamento
Entender a dinâmica de poder é o que diferencia a BSA de um analista de requisitos. Aqui você vê: a posição de cada pessoa (a favor, neutro, resistente), o nível de influência real e a jogada certa para cada uma.
Champions — as pessoas que puxam por você dentro da Dataprev
Por que é seu champion: além de ter pedido o suporte via WhatsApp e a notificação "estilo FGTS" na pré-venda, conduziu a Semana 0 e plantou a semente de Agentforce (FAQ no portal) com boa recepção. O Status Report semanal dele é agora a fonte operacional do projeto.
Como engajar: alimente com material de Agentforce informacional (web/portal) e referências de governo. Não puxe WhatsApp transacional agora. Ele é o amplificador da narrativa de inovação junto aos decisores.
Por que é seu champion: validou o modelo de residência de dados (AWS SP + CDP Oracle on-prem), endossou o uso de IA no monitoramento e trouxe o flag crítico dos adquirentes (50M consultas/dia não autenticadas) — ele trabalha pelos seus argumentos.
Como engajar: manter canal técnico aberto. Qualquer decisão de arquitetura deve passar por ele antes de chegar nos executivos.
Por que é seu champion: lidera a frente de IA da Dataprev que o PAT quer reutilizar — é a ponte natural entre o que já existe internamente e o que a Salesforce pode adicionar.
Como engajar: posicionar a Salesforce como complemento e acelerador do que ela já construiu — não como substituta. Ela precisa sair de cada reunião sentindo que ganhou, não que foi substituída.
Time de conta Salesforce — quem entrega e quem assina pelo lado da Salesforce
Papel no deal: responsável pelo relacionamento comercial da conta Dataprev na Salesforce. É quem garante o alinhamento executivo, a progressão do deal e a continuidade do engajamento entre ciclos de projeto.
Como acionar: envolver nas conversas com Antônio Jaime e Flávio Ronerson — ela é o elo comercial que sustenta a narrativa de parceria de longo prazo, além do projeto PAT.
Papel no deal: lidera a entrega técnica do Professional Services Salesforce. É o responsável pela qualidade arquitetural da solução e pelo comprometimento de prazo junto ao time técnico da Dataprev.
Como acionar: envolver nas discussões com Jair Bogo e Nelson Stebulaitis — ele é a contraparte técnica executiva que dá credibilidade às decisões de arquitetura e ao plano de entrega.
Gatekeepers técnicos — influentes, neutros, orientados a fatos
Dono das decisões de integração: MuleSoft, mock do Novo PAT, modelo de API para facilitadoras. Não está contra — está na zona de "mostre como funciona". Precisa de respostas técnicas sólidas, não de pitch.
Âncora do compliance regulatório (Decreto 12.712/2025, teto de 3,6%, split). Na oficina, como Líder de Produtos junto com Marina, deu feedback positivo ao processo e está ansioso pela discussão de sustentação com o CSM.
Liderança DTP na oficina: feedback positivo e porta da sustentação
O time in loco Salesforce reconheceu a potência técnica da equipe atual DTP, distinta dos perfis vistos em UNA e em Serviço na Ponta. ~30 pessoas DTP/MTE em discussões profundas. Isso pesa no sucesso.
Feedback pedido por Rafa após a oficina: muito positivo. Confia no processo, reconhece profissionalismo. Voltou a indicar que os painéis Tableau contratados devem permanecer, mesmo com Analytics DTP atuando. Ansiosa pela discussão de sustentação.
Feedback positivo na oficina. Criou os convites recorrentes no Teams a partir do pacote de ritos do Rafa. Quer a discussão de sustentação como um todo. Já tem modus operandi do lado DTP. É peça-chave para conectar esse modo ao suporte Salesforce (CSM + eventual L2 de PS após 18/DEZ).
Decisores executivos: quem assina e quem bloqueia
Fala o idioma de valor de negócio, ROI e visibilidade política. A mensagem para ele: "a Salesforce torna o programa fiscalizável, gera receita recorrente para a Dataprev via taxa no split e serve de template para outros ministérios". Evite linguagem técnica — vá direto ao valor.
O senso de urgência da mesa — cobra os marcos de setembro e novembro acima de qualquer outra coisa. Qualquer apresentação para ele precisa começar e terminar em: "entregamos no prazo e sem surpresas". Riscos que fogem ao controle da Salesforce devem ser nomeados antes que ele descubra.
Ameaça externa — não estão na mesa, mas podem bloquear
💰 Thread Comercial & Nexos de Plataforma Estratégia de conta
Onde estamos no deal, o que acontece nos próximos marcos, e como o PAT se conecta com as outras frentes ativas na Dataprev para construir uma narrativa de plataforma — não só de projeto.
Timeline do deal
O que conversar agora (e o que não forçar)
🤖 Agentforce · FAQ no portal (semente plantada)
FAQ no portal (web) e, em discussão interna, POC no site do MTE no lugar do Celeste. Transacional (WhatsApp) fica para depois. Ainda sem volume de atendimento. Não usar rascunho de “1.000 req/dia” como baseline.
Janela: agora, condicionado ao ateste de soberania. O baseline de consumo está no Backbone de licenças.
🛠️ Sustentação L2 por PS após 18/DEZ
Alinhamento Juliana Brites + Saulo/DTP. Indicação de que o nível 2 pós-projeto poderá ser feito por nós. Marina, Fabrício e Georges estão ansiosos. Conectar o modus operandi DTP ao CSM (Rudi).
Janela: agora até o Go Live · porta já aberta
🔌 MuleSoft · sustentação e governança
Desenho fechando (porta única, Lakehouse, microbatch). O que trava a Sprint 2 é VPN/A3/Git/logs/admin até 16/SET. Dois TCs já alocados.
Janela: esta semana · acessos 16/SET
📊 Tableau · painéis contratados se mantêm
Painel totalizador no Go Live é entrega do projeto. SUDA fica com análise aprofundada. Data Cloud não forçar agora.
Janela: recorte totalizador vs SUDA · Analytics Salesforce em 19/OUT
Nexos de plataforma — as 4 frentes Dataprev como um ecossistema
A Dataprev não é cliente de projeto — é cliente de plataforma. Cada frente que você entrega junto fortalece a narrativa de que a Salesforce é o sistema operacional digital do trabalhador brasileiro.
| Frente | O que é | Nexo com o PAT | Narrativa que conecta |
|---|---|---|---|
| Frente 1 Agentes + Mensageria WhatsApp/Slack |
30M mensagens contratadas. Agente INSS Perícias Médicas em validação. Fluxos Slack entregues. | Notificação ao trabalhador via WhatsApp quando crédito PAT é depositado — mesmo canal, mesmo agente, nova régua de comunicação de benefícios. | Dataprev como canal oficial de comunicação do governo com o cidadão-trabalhador. |
| Frente 2 Data Ágil · Slack + Agentforce gov |
Slack + Agentforce como camada de colaboração interna para o governo. Proposta em andamento com Pedro. | A equipe do MTE e da Dataprev que fiscaliza o PAT precisa de uma camada de colaboração. Data Ágil é exatamente isso — e integra com os casos de fiscalização abertos no Service Cloud do PAT. | Dataprev como ambiente de trabalho inteligente — inovação de dentro para fora. |
| Frente 3 PAT Marketplace (este projeto) |
SOW assinado US$970K. Sprint 2 em curso (14 a 18/SET). Linha de base: 11 épicos, 45 funcionalidades, 195 histórias, 4.670 SPs. Go Live 15/NOV. Pronto interno 06/NOV. Fim do projeto 18/DEZ. | — | Dataprev como plataforma de governança de mercados privados de benefícios ao trabalhador. |
| Frente 4 Data Mulheres · BI / Tableau |
Tableau Server on-prem. Oportunidade R$ 904K em Stage 02. BD Oracle/PostgreSQL on-prem. | O PAT gera 30M transações/dia — é um dataset imenso de inteligência de mercado. O Tableau para o MTE visualizar esse volume é o argumento mais concreto de ROI para a Frente 4. | Dataprev como hub de inteligência de dados do trabalhador brasileiro. |
Backbone de licenças
O Go Live desta org é portal (login) e processo. Agentforce, se entrar, é outra régua: actions, não login. Transação de vale não é atendimento. Esta seção separa as três coisas, para a análise do contrato ilimitado.
Quem precisa de crachá neste programa Leitura 15/SET
Existe uma analogia simples. Imagine um refeitório. Quem atravessa a porta precisa de um crachá: é o login do portal. O almoço que sai da cozinha não precisa de crachá. A maquininha que pergunta “este restaurante pode aceitar o vale?” também não é um conviva novo. É só um recado para a lista da cozinha. Se um dia houver um atendente de IA na porta, o que se cobra nele não é o crachá. É cada pedido que ele resolve. O PAT mistura esses movimentos no mesmo programa. O Go Live só contrata o crachá.
A org deste marketplace já existe e está em desenvolvimento. Ela não é a org Dataprev (UNA, Serviço na Ponta). A pergunta do contrato ilimitado é se ele pode cobrir esta org do MTE. O que segue não é uma cotação. É o mapa de quem loga, o que já foi contratado e o que o volume de vale faz (e não faz) com a plataforma. A quantidade final de cada produto continua com o Deal Desk.
A régua do Agentforce é outra
Agentforce não se licencia por login de portal. O consumo comercial é o que o agente faz: actions (Flex Credits) ou conversas, conforme o modelo do contrato. Um atendimento pode disparar várias actions. Login no Experience, transação de vale e consulta no PDV não entram nessa conta. Fonte da régua: Salesforce Agentforce Pricing e a Flex Credits Rate Card de 31/08/2026 (ação padrão: 20 créditos).
Dois números para cada coisa
Há um teto a perseguir, o da Nota Técnica, e há o que o discovery enxergou na operação. O teto dimensiona capacidade. O discovery dimensiona concorrência e rajada. Os dois são verdadeiros. Não se escolhe um e se descarta o outro.
| Quem ou o quê | Teto a perseguir | O que o discovery viu | Onde isso acontece | Pede licença Salesforce? |
|---|---|---|---|---|
| Empresas beneficiárias | até 1 milhão | até 450 mil | Portal Experience. A pessoa entra com gov.br. | Sim. Cabe na Community Login já contratada. |
| Estabelecimentos | até 1 milhão | até 750 mil | Portal Experience. O mesmo tipo de entrada. | Sim. O mesmo pool de login. |
| Facilitadoras | até 1.000 | até 500 | API no Mule. Não há portal. | Não. Sistema falando com sistema. |
| Trabalhadores | até 30 milhões | até 22 milhões | CTPS Digital. Aviso de crédito, sem saldo nem extrato no Experience. | Não. Sem login. Sem Agentforce. |
| Transações de vale | 30 milhões por dia. Se cada pessoa fizer uma refeição, o discovery aponta 22 milhões. Mais de uma refeição no dia justifica o teto de 30. | até 22 milhões por dia (uma refeição) | Lakehouse. A Salesforce recebe o arquivo. Não processa no Core. | Não. Não é pessoa na porta. Não é conversa de agente. |
| Consulta no ponto de venda | Não é um segundo teto. Os 50 milhões por dia que circularam no início do projeto eram o volume esperado antigo de transação, a mesma família. | Sem cache, no máximo o número de transações. Com cache do estabelecimento, menos da metade: mais de uma pessoa come no mesmo lugar no mesmo dia. | Uma consulta rápida no Mule, com a lista local. | Não. Não soma consumo na org. |
Três camadas, um único número
Trinta milhões de transações por dia são vendas de vale no estabelecimento: valor, data, hora, CNPJ, CPF. A pergunta natural é se isso vira trinta milhões de licenças, de logins ou de atendimentos de agente. Não. O número atravessa três camadas. Só a primeira pede licença.
1. Quem entra
Named user interno e Community Login já contratada. Conta cabeça e login no portal. Não conta o cartão na maquininha, a consulta do ponto de venda, nem o que um agente de IA faria se a POC avançar. Agentforce não mora nesta camada.
2. O teto da org
Limites coletivos, independentes de quantas pessoas logam: chamadas de API no dia, Bulk, storage, eventos de plataforma, Apex assíncrono. Se trinta milhões de linhas caíssem aqui como registro CRM, a org estoura. Por isso o trilho não cai aqui.
3. Fora da org
Mule no perímetro Dataprev, Lakehouse, Oracle, cache do estabelecimento. A Salesforce recebe a transação nessa camada. O Core fica com processo, exceção e o totalizador Tableau.
O que trinta milhões de almoços pedem à plataforma
Receber esse volume está no escopo. Processar cada linha como objeto CRM não está, e não deve estar. Uma transação de vale não abre sessão e não é um atendimento Agentforce. Se a POC de agente no site do MTE avançar, o que entra no contrato é quantidade de atendimentos (para então estimar actions). Esse número ainda não existe neste material.
Ordem de grandeza ilustrativa · org Enterprise com 100 named users · não é cotação
O teto diário da org é da ordem de centenas de milhares. Trinta milhões não cabem. A escala do gráfico é visual, não linear.
Objeto customizado conta 2 KB por linha, qualquer que seja o tamanho do campo. Trinta milhões de linhas pesam cerca de 60 GB. Uma org Enterprise com 100 named nasce com cerca de 12 GB.
Na alocação padrão Enterprise, a plataforma entrega 25 mil eventos de alto volume em 24 horas. Trinta milhões passam de mil vezes esse teto.
Bulk API 2.0 aceita até 150 milhões de registros em 24 horas. Trinta milhões cabem (20% do teto). O cano resolve carga. Não transforma o CRM em repositório de cada almoço do país.
Fontes dos tetos: Salesforce Developers (API Request Limits, Bulk API Limits, Platform Event Allocations) e Salesforce Help (Data and Storage Resources, cerca de 2 KB por registro). As barras de API e de evento mostram ordem de grandeza, não escala linear.
O restante da volumetria, na mesma conversa
| O número | O que isso é, na prática | Se caísse no Core | O que isso significa para o contrato |
|---|---|---|---|
| Consulta no PDV A mesma família da transação, não um segundo teto |
Antes da maquininha aceitar o vale, o Mule consulta se o estabelecimento está apto. A lista fica em cache. Sem login. Resposta em no máximo 3 segundos, o dia inteiro. | Mesmo o discovery (22 milhões de consultas sem cache) estoura o teto diário de API. Com cache, o volume cai para menos da metade das transações. | Isso é capacidade de Mule e de cache. Não pede licença e não soma cinquenta milhões na org. |
| Community Login, 1,2 milhão de usuários Já contratada · discovery 450 mil + 750 mil CNPJs |
Quem entra nos três portais, com SSO a partir do Novo PAT e do gov.br. Cada pessoa que entra no dia consome um login único, mesmo que entre várias vezes. Esta família de licença não cria Account no contexto do usuário do portal. O time trata isso em componente próprio. Não havia outra família de licença sem um salto grande de custo. | Comprar cadeira named para cada CNPJ do teto seria a tradução cara, e sem relação com o uso real. Community Login não aumenta o teto de API da org. | O pool já está contratado. Member-based não volta a esta conversa. O trabalhador fica de fora. |
| Facilitadoras: até 500 no discovery, teto 1.000 | Sistemas, não pessoas. Consultam cotação, enviam proposta, folha e contrato em PDF. Sem portal. | Quinhentas facilitadoras perguntando a cada minuto geram 720 mil chamadas no dia contra o Mule. Se isso fosse REST na Salesforce, uma org Enterprise com 100 named estoura de manhã. | Fila, retry e certificado no perímetro. Não é Community. |
| Trabalhadores: 22 a 30 milhões | O cidadão vê um aviso de crédito na CTPS Digital. Não entra no Experience. Não consulta saldo nem extrato ali. | Nenhum governor de usuário, a menos que alguém crie dezenas de milhões de usuários de portal. | Integração Mule com a CTPS. Zero licença. Este número não descreve atendimento de agente. |
| Folha, Cenário A Fechado em 14/SET |
A empresa envia o arquivo da competência. A facilitadora puxa e gera o boleto. Pico entre os dias 20 e 25. Um arquivo típico tem cerca de 10 mil linhas. | Se cada linha virasse registro CRM no pico, storage e Bulk brigam com a mesma lógica das transações. O arquivo vai para o perímetro. No Core fica o metadado de controle. | Fila de integração, não Community. |
| Agentforce POC. Fora do Go Live de 15/NOV. Sem volume de atendimento. |
Semente de FAQ no portal. Há uma conversa, ainda fria, sobre o site do MTE no lugar do Celeste. O consumo comercial, se houver, é action ou conversa, não login de Community. | Não se compara com o Core. Não substitui a transação de vale. Sem série do Celeste, não há conta de actions no mês. | Não entra no baseline desta org até existir quantidade de atendimentos. O ateste de soberania vem antes de qualquer POC. |
O que entra nesta org, produto a produto
| Produto | Para quê, nesta arquitetura | Como dimensionar | Leitura para o contrato | Fase 1 (15/NOV)? |
|---|---|---|---|---|
| Salesforce Platform | Modelo de dados, automação, operadores internos da Dataprev e do MTE. | Dezenas a baixa centena de named users. Não os milhões de CNPJs. | Licença named (Salesforce / Platform). | Sim. É o Core do Go Live. |
| Service Cloud | Casos de credenciamento e de fiscalização. | Um recorte dos named internos. Não é licença da empresa nem do restaurante. | Service Cloud nas cadeiras que abrem caso. | Sim. |
| Experience Cloud | Três portais, com entrada pelo Novo PAT e pelo gov.br. | Community Login, 1,2 milhão de usuários, já contratada. Discovery: 450 mil + 750 mil. Esta família não cria Account no contexto do portal. | O pool já está contratado. Member-based não volta a esta conversa. Trabalhador e facilitadora ficam de fora. | Sim. As cascas saíram na Sprint 1. |
| OmniStudio | Formulários de cotação e o caminho da folha, se o desenho usar OmniScript. | Add-on da org, não licença de quem entra no portal. | Pendente de confirmação no contrato Dataprev. | Sim, se cotação ou folha usar OmniScript. |
| Shield | Criptografia e trilha de auditoria no dado que passa pelo Core. | Não é por usuário. | Platform Encryption e Field Audit Trail. | Sim. |
| MuleSoft (on-prem Dataprev) | A porta única: facilitadoras, Receita, gov.br, Novo PAT, CTPS, consulta de PDV e a chegada da transação. | Até 500 facilitadoras no discovery. Transação de 22 a 30 milhões por dia no Lakehouse. PDV abaixo disso, por causa do cache. | Capacidade no perímetro Dataprev. Não é Community. | Sim. Receber a transação está no escopo. |
| Tableau | O painel totalizador do projeto. A análise profunda fica com o SUDA. | Cadeiras individuais, não um milhão de CNPJs. | As cadeiras precisam bater com o que já está no contrato Dataprev. | Totalizador no Go Live. |
| Agentforce | Semente de FAQ no portal. Conversas, ainda frias, sobre o site do MTE no lugar do Celeste. | Por atendimento e action (Flex Credits ou conversa), não por login de portal. Ainda sem série de atendimentos. | Fora do baseline do Go Live. Ateste de soberania vem antes. | POC. Não é entrega contratual de 15/NOV. |
| Slack | Canal do projeto. | Cinquenta cortesias no workspace Dataprev. O canal External já está no ar. | Não mistura com as licenças desta org. | Operação do time. |
| Hyperforce Brasil | Onde mora a camada de processo e metadado. | Não é licença de usuário. Dado ultrassensível permanece on-prem. | Esta org nasce em Hyperforce Brasil. | Sim. Premissa de soberania. |
| Data Cloud, Marketing Cloud, Public Sector Solutions | Sem caso na Fase 1. O bundle de Industries foi descartado de propósito. | Não se aplica | Fora deste baseline. | Não. |
O que consome a org, além da contagem de cadeiras
O contrato não se decide só pela lista de produtos. Duas frentes tocam esta org no Go Live. A transação de vale permanece de propósito fora do Core. Agentforce só entra se a POC avançar, e aí a régua muda.
Logins nos portais
Essa licença já está contratada: Community Login, 1,2 milhão de usuários. Não há série histórica de quantas pessoas entram por dia. O pico esperado é o recadastro e a folha, entre os dias 20 e 25, sobre a base de discovery (450 mil empresas e 750 mil estabelecimentos). Esta licença não soma chamada de API na org e não gera action de Agentforce.
Integração e rajada
Até 500 facilitadoras consultando cotação. A folha da competência na mesma janela do mês, no Cenário A. Recadastro em massa (60 dias) e cerca de 300 arquivos de migração. Monitorar DailyApiRequests, DailyBulkApiRequests e DailyAsyncApexExecutions.
Agentforce: ainda sem atendimento
Não está no Go Live. Se a POC no site do MTE avançar, o que falta para o baseline é quantidade de atendimentos do bot atual (Celeste), para então estimar actions no mês. O rascunho interno de “1.000 requisições por dia por licença” não é esse número. Receber até 30 milhões de transações no Lakehouse não entra nesta conta.
Leitura cruzada em 15/09/2026 com o time de arquitetura e delivery (Nelson Stebulaitis Filho, Rafael Roquette, Eric Gasparotto). Tetos da Nota Técnica oficial, agosto/2026. Folha no Cenário A, 14/09/2026. Community Login 1,2 milhão já contratada, confirmada pelo delivery. Alinhamento interno de 14 e 15/09/2026 sobre o baseline desta org para a análise do contrato ilimitado. Agentforce: modelo comercial em actions (Flex Credits) ou conversas, não em login de portal. Ver Salesforce Agentforce Pricing e Flex Credits Rate Card de 31/08/2026. Sem série de atendimentos do Celeste neste material. Limites de plataforma: Salesforce Developers (API Request Limits, Bulk API 2.0, Platform Event Allocations) e Salesforce Help (Data and Storage Resources, Experience Cloud User Licenses, cerca de 2 KB por registro). As contas de “30 milhões × 2 KB” e “500 × 1.440 consultas” são ordem de grandeza, não cotação. Produto e quantidade final: Deal Desk.
Como a Salesforce pode operacionalizar o novo Marketplace do PAT da Dataprev
Análise estratégica e de implementação a partir da reunião de apresentação de demanda (Dataprev × Salesforce, 21/07/2026), cruzada com o marco regulatório do Decreto 12.712/2025 e dados públicos de mercado. Este documento é o raciocínio vivo em 6 partes: do entendimento do negócio à priorização de casos de uso e KPIs.
Como ler este material
Cada parte responde a uma pergunta de negócio e alimenta a próxima. A navegação lateral segue a ordem lógica do raciocínio de BSA.
1 Entendimento do Negócio
O que é o PAT, a virada regulatória, os atores e a volumetria. Fatos da reunião + fontes públicas.
2 Objetivo de Negócio
O que o MTE e a Dataprev querem de fato alcançar, e quais dores estão resolvendo.
3 Análise Técnica Salesforce
Quais produtos e capacidades Salesforce endereçam cada necessidade.
4 Arquitetura Macro
Baseline da oficina 04/SET, os dois caminhos de folha, integrações, residência de dados e camadas.
5 Jornadas & Casos de Uso
Fluxos com e sem Agentforce (quando o agente não couber).
6 Priorização & KPIs
Quick wins x complexidade técnica e os indicadores de cada caso.
7 Visão Estratégica Futura
PAT como plataforma de inteligência de dados e política pública — a granularidade transacional que o MTE quer atingir.
1.1 O que está em jogo: o PAT e a virada regulatória Contexto
O PAT (Programa de Alimentação do Trabalhador) dá base legal ao vale-alimentação (VA) e vale-refeição (VR). Criado pela Lei 6.321/1976, sob um pacto simples: a empresa concede o benefício e ganha desoneração fiscal (fora de FGTS e IR). O projeto nasce de uma mudança regulatória recente e profunda.
Decreto nº 12.712, de 11/11/2025, o gatilho do projeto
Altera o Decreto 10.854/2021 (na esteira da Lei 14.442/2022). Confirma exatamente o que foi dito na reunião e detalha o cronograma de vigência escalonado.
| Regra nova | O que muda | Vigência | Fonte |
|---|---|---|---|
| Teto de MDR | Taxa de desconto ao estabelecimento limitada a 3,6% (antes ~8,5%) | desde 10/02/2026 | Decreto 12.712/2025, art. 182-B |
| Tarifa de intercâmbio | Limitada a 2% | 90 dias | Decreto 12.712/2025, art. 182-B |
| Prazo de repasse | Liquidação em até 15 dias corridos (antes 30+) | desde 10/02/2026 | Decreto 12.712/2025, art. 182-C |
| Arranjos abertos | Obrigatórios para operadoras com >500 mil trabalhadores | 180 dias | Decreto, art. 174 §1º |
| Interoperabilidade plena | Qualquer cartão aceito em qualquer maquininha | transição 05/2026, plena 11/2026 | Decreto, art. 177 |
| Vedações | Proibição de deságio e de benefícios acessórios (academia, saúde, crédito) | imediata | Decreto, art. 3º / 182-F |
1.2 Quem é a Dataprev nesse arranjo Ator
Estatal de TI que operacionaliza sistemas do MTE. A divisão presente (Benefício ao Trabalho) já opera Seguro-Desemprego, Abono Salarial, CAGED e o Crédito do Trabalhador (consignado da CTPS Digital), e recebeu agora o PAT. A experiência do Crédito do Trabalhador é a analogia-chave: quase 100% dos acessos das instituições financeiras são via API, com resposta automática em segundos.
1.2.1 Quem é quem na mesa Mapa de stakeholders
O material cita várias pessoas da reunião. Este é o elenco: quem apresenta a solução, quem puxa a inovação e quem assina o contrato. Entender o papel de cada um orienta a comunicação (o discurso técnico para uns, o de valor e prazo para os decisores).
Ancorou o enquadramento regulatório (Decreto 12.712/2025, teto de 3,6%) e fixou a regra de ouro do financeiro: a lógica do split fica na plataforma do MTE, o banco só executa.
Traduziu o objetivo do MTE: aumentar a gestão sobre o programa, gestão, fiscalização e monitoramento, para fazer cumprir a lei.
Integra a área técnica que apresenta a solução, contribuindo no detalhamento dos módulos e das integrações do programa.
Dono da tese de integração: facilitadoras operam por API (não por portal) e o Novo PAT, imaturo, exige trabalhar com mock. É o racional que sustenta a escolha do MuleSoft.
Confirmou o modelo de residência (instância AWS em São Paulo + CDP Oracle on-premise), levantou o controle de acesso por facilitadora e endossou o uso de IA no monitoramento.
Pediu o suporte via WhatsApp (o gancho do Agentforce), sugeriu a notificação ao trabalhador "estilo FGTS" e sinalizou que a solução abre caminho para outros ministérios, a narrativa de expansão.
Lidera a frente de IA e agentes ("serviço na ponta") citada como ativo reaproveitável no PAT: motor de fluxo, CDP e agentes já em operação na Dataprev.
Responsável pelo relacionamento comercial da conta Dataprev. Garante a progressão do deal, o alinhamento executivo com Antônio Jaime e Flávio Ronerson, e a narrativa de parceria de longo prazo além do projeto PAT.
Lidera a entrega técnica do Professional Services Salesforce. Contraparte executiva do time técnico Dataprev (Jair, Nelson) — é quem assegura a qualidade arquitetural e o comprometimento de prazo do lado Salesforce.
Superintendente na governança do fechamento. É com ele e o Flávio que o contrato será fechado: interlocutor do valor de negócio e do compromisso de entrega.
Diretor que pressiona por definições rápidas por causa dos marcos de setembro e novembro. É o senso de urgência da mesa: prazo político acima de tudo.
1.3 O que a Dataprev está construindo, 4+1 módulos Solução
Uma plataforma de governo (marketplace + gestão) que se posiciona entre beneficiárias, facilitadoras, estabelecimentos e o MTE. Não substitui o cadastro oficial (que fica no "Novo PAT" do MTE), mas se integra a ele.
1 Marketplace de Cotação & Contratação
Balcão digital onde a beneficiária publica a necessidade e as facilitadoras enviam propostas padronizadas.
A necessidade inclui nº de funcionários, valor, VA/VR/misto, UF e vigência. Comparação e escolha na plataforma, mas o contrato é fechado diretamente entre as partes. Dinâmica de leilão, não e-commerce de prateleira.
2 Financeiro (folha + custódia + split)
Upload de folha em layout único, pagamento em conta custódia de banco público e split automático.
Geração de boleto (potencial Bolex/Pix BB); o split cobre taxa MTE/Dataprev + repasse à facilitadora. A regra do split reside na plataforma do MTE; o banco só executa.
3 Credenciamento de Estabelecimentos
Pré-cadastro unificado via GOV.BR; a facilitadora consulta, aprova, pede dados ou descredencia via API.
Mudança de última hora: a aprovação/fiscalização/descredenciamento continua com as facilitadoras; o marketplace vira a base unificada.
4 Monitoramento (fiscalização a posteriori)
Facilitadoras enviam as transações por API e o MTE identifica padrões anômalos. Não bloqueia venda, é análise posterior.
Dados: estabelecimento, valor, data/hora, CPF (futuramente categoria do produto). Anomalias como vendas de madrugada, valores atípicos e estabelecimentos suspeitos.
+ Notificação ao Trabalhador via CTPS Digital
Aviso de previsão de crédito no app (modelo similar ao FGTS).
Não é gestão de saldo nem extrato de compras: apenas o aviso do crédito a ser disponibilizado pela facilitadora, consultável na CTPS Digital.
Fluxo macro do marketplace (visão de leilão)
1.4 Glossário dos atores Combinado na reunião
| Ator | Papel | Como acessa |
|---|---|---|
| Facilitadora | Emite/opera o cartão (Sodexo/Pluxee, Alelo, VR, Caju, Ticket). Fiscaliza e credencia estabelecimentos. | API |
| Beneficiária | Empresa que contrata o benefício para seus funcionários. | GOV.BR + procuração digital |
| Estabelecimento | Supermercado, restaurante, padaria que aceita o vale. | GOV.BR |
| MTE | Dono do programa. Quer gestão, fiscalização e monitoramento. | Painéis / gestão |
| Novo PAT | Sistema pré-existente do MTE (feito pela DTI do Ministério) que credencia beneficiárias, facilitadoras e nutricionistas. | Integração (API) |
| Trabalhador | Beneficiário final do crédito de alimentação/refeição. | CTPS Digital |
1.5 Volumetria: o que disseram × o que confirma o mercado Dados
Os números da Dataprev batem em ordem de grandeza com as fontes públicas. Isso valida a estratégia de API (centenas de milhares de beneficiárias contra poucas centenas de facilitadoras, sendo 5 dominantes). Nota Técnica oficial (ago/2026) revisou os tetos para cima.
| Dimensão | Antes (reunião jul/2026) | Depois (Nota Técnica oficial) |
|---|---|---|
| Trabalhadores beneficiados | 22–24M | até 30M |
| Empresas beneficiárias | ~450–470K | até 1 milhão |
| Estabelecimentos credenciados | ~743–800K | até 1 milhão |
| Facilitadoras | 500–700 | até 1.000 |
| Transações monitoradas | — | 30M transações/dia |
RNFs confirmados (Nota Técnica) Performance
🖥️ Módulo de Gestão
Disponibilidade 99,5% · seg–sex 7h–22h
Janela de operação administrativa com SLA de alta disponibilidade.
🔌 Marketplace e API
24/7 · SLA 99%
Operação ininterrupta para facilitadoras e adquirentes, sem janela de manutenção.
⚡ Tempo de resposta
≤3s em 95% das requisições
Requisito crítico para consultas em tempo real no PDV (adquirentes) e no leilão.
Adquirentes: volume silencioso de ~50M consultas/dia Novo ator
Monitoramento de APIs: previsibilidade e geração de alertas Requisito Dataprev
A Dataprev levantou explicitamente a necessidade de previsibilidade de consumo e geração de alertas antes de atingir limites de API — não monitoramento reativo. O contexto é o volume combinado abaixo e a stack Elasticsearch já existente no cliente.
/services/data/vXX.0/limits da Salesforce (disponível sem Shield, retorna consumo atual × teto da org) via Logstash, indexar com timestamp e configurar alertas Kibana com threshold (ex.: >80% do limite → notificar). Intervalo sugerido: a cada 5 minutos.Limites críticos a monitorar:
DailyApiRequests (chamadas REST/SOAP 24h), DailyBulkApiRequests (Bulk API), DailyAsyncApexExecutions (jobs assíncronos), ConcurrentAsyncGetReportInstances (relatórios simultâneos).Nota: Event Monitoring (Shield) não é pré-requisito para alertas de consumo — só adiciona granularidade por usuário/endpoint. O endpoint
/limits é suficiente para previsibilidade e alertas de threshold.
| Componente | Papel | Salesforce |
|---|---|---|
Salesforce /limits API | Fonte de dados de consumo em tempo real | Nativo · sem add-on |
| Event Monitoring | Log granular por usuário, endpoint e Connected App | Shield ou add-on (opcional) |
| Logstash | Coleta periódica e envio ao Elastic | Stack própria Dataprev |
| Elasticsearch + Kibana | Armazenamento, dashboards e regras de alerta | Stack própria Dataprev |
| MuleSoft | Alternativa orquestrada para pipelines já existentes | Se já estiver na arquitetura |
10 itens fora do escopo de novembro Fora do escopo
Confirmados pela Nota Técnica + alinhamento com Nelson. Não entram na entrega de nov/2026.
| # | Item excluído | Observação |
|---|---|---|
| 1 | Wallet CTPS | Carteira digital do trabalhador via CTPS Digital — fase posterior. |
| 2 | Arranjo financeiro no PDV | Processamento de pagamento em tempo real no ponto de venda. |
| 3 | Bloqueio por TIP | Restrição de transações por Tipo de Infração de Programa. |
| 4 | Portabilidade ativa | Migração de benefícios entre facilitadoras a pedido do trabalhador. |
| 5 | Denúncias via CTPS | Canal de reclamação do trabalhador via CTPS Digital. |
| 6 | Consulta de saldo | Saldo disponível em tempo real para o trabalhador. |
| 7 | White-label para facilitadoras pequenas | Interface personalizada para facilitadoras de menor porte. |
| 8 | APIs do Novo PAT (MTE) | Responsabilidade do MTE/DTI — fora do escopo Dataprev/Salesforce. |
| 9 | Gestão de licitações | Módulo completo de licitação pública — não entra na Onda 1. |
| 10 | Integração NFC-e / Receita Federal | Nota Fiscal de Consumidor Eletrônica — integração fiscal futura. |
1.6 Restrições, dependências e prazos Riscos iniciais
🔒 Residência de dados
Dados sensíveis (CPF, transações) não podem ficar em nuvem externa. É o maior desafio arquitetural.
Padrão Dataprev do "serviço na ponta": CDP Oracle on-premise no data center, com o restante em AWS São Paulo (residência nacional).
🧩 APIs imaturas
Integração mais crítica e arriscada: o Novo PAT, ainda em construção, sem arquitetura, Swagger ou definição pronta.
Estratégia acordada: descoberta em tempo de projeto + mocks em homologação. As demais integrações já são mais conhecidas internamente.
Cronograma sinalizado
Dependências de integração Material Dataprev, "Possíveis Dependências"
O próprio material da Dataprev (deck "PAT · Fábrica") lista as integrações necessárias. Reproduzimos a tabela oficial abaixo, com a correção do que na reunião havia sido anotado como "Kinis": as fontes cadastrais corretas são o CNIS PJ (empregadores) e o CNIS PF (trabalhadores).
| Produto / Fonte | Funcionalidade | Descrição |
|---|---|---|
| Novo PAT crítico | Credenciamento de beneficiárias e facilitadoras | Integração via API para validação cadastral. Pode demandar desenvolvimento adicional do lado da DTI do MTE. |
| CTPS Digital e Portal do Trabalhador | Notificações ao trabalhador | Integração para informar os créditos de VA/VR ao trabalhador. |
| Gov.br | Autenticação | Login de beneficiárias e trabalhadores via Gov.br (nível prata/ouro). |
| GERID MTE | Autenticação | Login dos usuários do MTE. |
| eSocial / Extrato | Dados das declarações | Fonte de dados complementar (ex.: batimento da folha com empregados declarados). |
| CNIS PJ | Dados das declarações | Dados dos empregadores (pessoa jurídica). |
| CNIS PF | Dados das declarações | Dados dos trabalhadores (pessoa física). |
| SDC | Dados corporativos | Dados estruturados de UF e municípios. |
| Facilitadoras | Dados para monitoramento | Informações das transações realizadas nos estabelecimentos. |
| Banco público | Transações com a conta custódia | Gestão do crédito e repasse financeiro (split). |
🎯 Fio condutor estratégico da Parte 1
O governo quer trazer para dentro de uma plataforma de Estado um mercado de R$ 150 a 200 bilhões que hoje é opaco e controlado por poucos players. A Dataprev precisa entregar isso em prazo apertadíssimo (set e nov/2026), com dados sensíveis on-premise e integrações ainda inexistentes, num ambiente de disputa jurídica com o mercado incumbente.
2.1 A pergunta central de negócio Framing
Antes de falar de tecnologia, é preciso separar quem quer o quê. Há três camadas de objetivo com interesses diferentes (e às vezes em tensão): o MTE (dono da política pública), a Dataprev (executora e operadora do trilho digital) e o ecossistema (trabalhador, beneficiária, estabelecimento, facilitadora). O sucesso do projeto depende de atender os três sem quebrar nenhum.
2.2 Objetivos do MTE, dono do programa Política pública
O objetivo declarado mais alto na reunião: "aumentar a gestão, fiscalização e monitoramento do programa". Tudo o mais é meio para isso.
🎯 Enforcement da lei
Garantir as regras do PAT: mesmo valor para todos os funcionários, uso exclusivo em alimentação, teto de taxas e prazo de repasse.
Hoje o MTE "depende das informações repassadas" e não consegue validar.
👁️ Visibilidade de mercado
Ter dados que hoje não existem: taxas praticadas, contratos fechados, rede de estabelecimentos e transações.
Sair da cegueira informacional.
⚖️ Concorrência e transparência
Quebrar a concentração (5 players dominam), dando visibilidade de taxas e abrindo espaço para facilitadoras menores.
A dinâmica de leilão pressiona preços para baixo.
🏪 Base unificada de estabelecimentos
Consolidar os ~800 mil estabelecimentos que hoje só existem nas bases privadas das facilitadoras.
Com poder de descredenciar irregulares (hoje ~0%).
🔎 Detecção de fraude e desvio
Identificar padrões anômalos: vendas de madrugada, valores atípicos, itens fora do rol permitido.
Gera fiscalização a posteriori.
💰 Arrecadação simbólica no split
Uma taxa pequena por operação, retida no split, remunera o serviço (MTE/Dataprev).
Cria a sustentação econômica da plataforma.
2.3 Objetivos da Dataprev, executora e trilho digital Negócio / entrega
⏱️ Entregar no prazo político
Homologar cotação + Novo PAT até set/2026 e produção completa até 15/11/2026.
Há pressão direta do diretor Flávio Ronerson.
🚄 Consolidar-se como o "trilho" de benefícios
O PAT adiciona mais um serviço nacional ao portfólio, reforçando o papel de plataforma única do trabalhador.
A Dataprev já opera Seguro-Desemprego, Abono, CAGED e Crédito do Trabalhador.
💵 Receita recorrente
Taxa de serviço por transação no split, sobre um volume de R$ 150-200 bi/ano.
Modelo de monetização escalável e previsível.
🌐 Expansão para outros órgãos
O padrão "abre caminho para outros ministérios": a plataforma vira ativo replicável.
Sinalização de Rafael Roquette na reunião.
♻️ Reaproveitar o que já existe
Aproveitar aprendizado e ativos do "serviço na ponta".
CDP Oracle on-premise, motor de fluxo/máquina de estado e agentes de IA (frente da Fernanda Souza).
🛡️ Soberania e conformidade de dados
Manter dados sensíveis (CPF, transações) com residência nacional e, idealmente, on-premise.
Coerente com o perfil de governança de dados da estatal.
2.4 Objetivos do ecossistema Stakeholders
| Ator | O que ganha (objetivo) | Risco / resistência |
|---|---|---|
| Trabalhador | Previsibilidade do crédito (notificação CTPS), mais estabelecimentos aceitando (interoperabilidade), benefício protegido de desvio. | Baixa. É o beneficiado final. |
| Beneficiária (empresa) | Comparar taxas, reduzir custo, layout único de folha, menos trabalho operacional, mais transparência. | Curva de adoção do novo canal e da autenticação GOV.BR. |
| Estabelecimento | Taxa menor (teto 3,6%), repasse mais rápido (15 dias), aceitação universal de cartões. | Nova etapa de pré-cadastro obrigatório na plataforma. |
| Facilitadora | Acesso automatizado via API, base unificada de estabelecimentos, menos atrito de credenciamento. | Alta. Perda de margem, transparência forçada e disputa jurídica (ABBT no STF). Integra por obrigação regulatória. |
2.5 Objetivos explícitos × implícitos Leitura estratégica
✅ Explícitos (ditos na reunião)
- Gestão, fiscalização e monitoramento pelo MTE
- Transparência e concorrência de taxas
- Base unificada de estabelecimentos
- Padronização de folha e split financeiro
- Notificação de crédito ao trabalhador
🔒 Implícitos (leitura BSA)
- Dar enforcement operacional a um decreto contestado no STF
- Reduzir o poder de barganha do oligopólio de facilitadoras
- Criar uma fonte de receita recorrente para MTE/Dataprev
- Posicionar a Dataprev como plataforma-âncora de benefícios do trabalhador
- Gerar um modelo replicável para outros programas/ministérios
🎯 North Star dos stakeholders (resumo)
3.1 Princípio de arquitetura de solução Tese técnica
A Salesforce entra como a camada de orquestração, regras, experiência e inteligência do programa, não como repositório do dado sensível bruto. O dado sensível (CPF, transações) segue a regra de residência da Dataprev; a Salesforce governa o processo, aplica as regras de negócio e expõe as jornadas. Isso permite entregar rápido sem violar a soberania de dados.
🧠 Orquestração & Regras
Flow, Apex e OmniStudio, sobre a Salesforce Platform, concentram máquina de estado, validações e a lógica de split (com percentuais versionados em Custom Metadata Types) que "tem que ficar na plataforma do MTE".
🔌 Integração desacoplada
MuleSoft é o barramento único para Novo PAT, GOV.BR, banco custódia, eSocial e as APIs das facilitadoras, com mock nativo para destravar prazos.
🔐 Soberania de dado
Hyperforce Brasil (AWS SP) para residência nacional em nuvem; dado ultrassensível permanece on-premise (padrão CDP Oracle já usado na Dataprev).
3.2 Mapa: objetivo / dor → capacidade → produto Salesforce Rastreabilidade
Cada linha conecta uma necessidade da Parte 2 ao componente que a resolve. É a espinha dorsal da proposta de solução.
| Necessidade / dor | Capacidade requerida | Produto / recurso Salesforce |
|---|---|---|
| Marketplace de cotação (leilão) | Portais autenticados, propostas padronizadas, comparação | Experience Cloud + Salesforce Platform (objetos + Flow) + OmniStudio |
| Regras do leilão e do split financeiro | Máquina de estado, regras versionadas e auditáveis | Flow + Apex + Custom Metadata Types + Shield (trilha) |
| Folha padronizada + boleto + custódia + split | Ingestão de arquivo, orquestração de pagamento, comando ao banco | OmniStudio DataRaptor/IP + MuleSoft + Flow/Apex |
| Credenciamento de estabelecimentos | Cadastro, workflow de aprovação, base unificada | Service Cloud (gestão de casos) + Flow Orchestration + Aprovações |
| Onboarding e acesso das facilitadoras por API | API gateway, segurança, rate-limit, visibilidade restrita | MuleSoft Anypoint (API Management) |
| Monitoramento e detecção de anomalias | Ingestão de transações, analytics, alertas | CDP Oracle on-prem (primário) + Tableau / CRM Analytics + Agentforce · Data Cloud opcional |
| Suporte informacional e transacional | Agente via WhatsApp / web chat para dúvidas e status | Agentforce (Service) + Digital Channels |
| Notificação de crédito ao trabalhador | Evento de folha → notificação na CTPS Digital | MuleSoft + Mensageria (reuso do "serviço na ponta") |
| Integração com Novo PAT (imaturo) | Consumo de API + mock para não travar homologação | MuleSoft (mocking / API-led) |
| Autenticação de beneficiária/estabelecimento | Login GOV.BR + procuração digital (empresas do CNPJ) | Experience Cloud SSO (OpenID Connect / GOV.BR) |
| Residência nacional de dados | Nuvem no Brasil + guarda on-premise do dado crítico | Hyperforce Brasil + Oracle on-prem (padrão Dataprev) |
3.2.1 Racional de escolha, produto a produto Por que este produto e não outro
Cada produto foi escolhido de forma individual, pela aderência à necessidade real do PAT, e não porque vem "junto no pacote". Abaixo, para cada peça: o papel no programa e por que ela foi escolhida.
| Produto Salesforce | Papel no PAT | Por que este produto |
|---|---|---|
| Salesforce Platform objetos, Flow, Apex | Modelo de dados do programa (cotação, proposta, contrato, estabelecimento, credenciamento) e automação de processos. | Dá controle total do modelo de dados, condição para a estratégia híbrida on-prem e para o leilão, que não é um objeto nativo de nenhuma indústria. Skills de core Salesforce são abundantes, o que protege o prazo. |
| Service Cloud | Gestão de casos de credenciamento (aprovar, pedir dados, descredenciar) e de fiscalização (anomalias viram casos rastreáveis). | Credenciamento e fiscalização são, na essência, casos com ciclo de vida, fila e SLA, exatamente o que o Service Cloud faz de forma nativa, com console, filas e histórico auditável. |
| Experience Cloud | Portais autenticados da beneficiária e do estabelecimento, com login GOV.BR. | Portais externos com SSO (OpenID Connect / GOV.BR) e componentes reutilizáveis, integrados ao mesmo modelo de dados. LWR entrega performance para volume público. |
| OmniStudio licenciável à parte | Wizards guiados de cotação e de intake de credenciamento; tratamento de arquivos de folha (DataRaptor / Integration Procedures). | Acelera jornadas com ramificação em low-code, encurtando a entrega dentro do prazo de set/nov. Usado como acelerador opcional, não como dependência do bundle. |
| Flow + Apex + Custom Metadata | Máquina de estado do leilão/credenciamento e o motor de regras do split (percentuais MTE × facilitadora) e das elegibilidades. | Motor de regras nativo da Plataforma: declarativo (Flow), com parâmetros versionados em Custom Metadata (deploy rastreável) e Apex só onde o cálculo exige. Auditável via Shield. Atende ao "a lógica fica na plataforma do MTE" sem depender de Industries. |
| MuleSoft | Barramento único de integração (Novo PAT, GOV.BR, banco, eSocial, facilitadoras) + API management + mocking. | Único componente que transforma o maior risco (APIs imaturas) em plano: mock nativo, API-led e Runtime Fabric on-prem para o dado sensível. Ver seção 3.4. |
| Data Cloud opcional | Base analítica de transações para o monitoramento. | Ingestão e unificação em escala quando houver necessidade de ativação/segmentação nativa. |
| Tableau / CRM Analytics | Painéis de gestão e fiscalização para o MTE. | Dá ao Ministério a visibilidade de mercado que ele nunca teve (taxas, contratos, transações, anomalias). |
| Agentforce | Atendimento nos canais (WhatsApp/web) e copiloto de fiscalização. | Pedido explícito do cliente na reunião; forte em linguagem natural e triagem, sempre com humano no loop. |
| Shield | Trilha de auditoria imutável das operações, sobretudo financeiras. | Programa sob escrutínio jurídico e político exige event monitoring e criptografia de campo comprováveis. |
| Hyperforce Brasil | Residência nacional em nuvem da camada de processo/metadados. | Residência de dados no Brasil (AWS SP), confirmada como viável na reunião; complementa a guarda on-prem do dado crítico. |
3.3 Como resolver, módulo a módulo Detalhe técnico
1 Marketplace de Cotação (leilão)
Experience Cloud entrega os portais da beneficiária e do estabelecimento com login GOV.BR. OmniStudio (OmniScript + FlexCards) monta o fluxo guiado de cotação e a comparação de propostas. A cotação é um custom object da Salesforce Platform com máquina de estado em Flow, e as facilitadoras interagem via API (não portal), consumindo e respondendo por MuleSoft.
2 Financeiro (folha, custódia, split)
Upload de folha em layout único tratado por DataRaptor / Integration Procedures. O motor de regras nativo (Flow + Apex, com percentuais em Custom Metadata Types) guarda a regra de split (percentual MTE x facilitadora), atendendo o requisito de que "a lógica fica na plataforma do MTE". MuleSoft comanda o banco público (custódia, boleto Bolex/Pix, split) e o Shield garante a trilha de auditoria financeira.
3 Credenciamento de Estabelecimentos
Caso de uso de gestão de casos no Service Cloud com Flow Orchestration: pré-cadastro via GOV.BR (status "pendente"), verificações automáticas (CNPJ ativo, CNAE compatível, situação fiscal) por MuleSoft, e workflow em que a facilitadora aprova, pede dados ou descredencia por API. Gera a base nacional unificada que hoje não existe.
4 Monitoramento (a posteriori)
Data Cloud ingere as transações enviadas pelas facilitadoras. Tableau / CRM Analytics gera painéis para o MTE (volumes, valores atípicos, estabelecimentos suspeitos). Agentforce atua como analista de fiscalização: detecta padrões anômalos (venda de madrugada, item fora do rol) e abre casos automaticamente.
+ Notificação ao Trabalhador (CTPS Digital)
O processamento da folha dispara um evento que, via MuleSoft, alimenta a notificação de previsão de crédito na CTPS Digital, reaproveitando a mensageria já operada pela Dataprev com a Salesforce. Modelo "estilo FGTS": só aviso de crédito, sem gestão de saldo.
3.4 A camada que decide o prazo: MuleSoft Caminho crítico
O maior risco da reunião foi a imaturidade das APIs, sobretudo o Novo PAT ("alto risco", "vamos ter que trabalhar com mock"). MuleSoft transforma esse risco em plano.
🧪 Mocking nativo
O Anypoint permite publicar contratos de API (specs) e servir mocks funcionais imediatamente. Times constroem contra o mock enquanto o Novo PAT real é finalizado, exatamente a estratégia acordada para o marco de setembro.
🔗 API-led connectivity
Camadas System, Process e Experience isolam cada integração (Novo PAT, GOV.BR, GERID, eSocial/Extrato, banco público, CNIS PJ/PF, SDC). Trocar o mock pela API real não impacta o resto da solução.
🚪 API Management para facilitadoras
Gateway com autenticação, rate-limiting e políticas de visibilidade: cada facilitadora só enxerga contratos e empregados das beneficiárias com quem fechou, resolvendo o controle de acesso levantado pelo Nelson.
🏠 Runtime híbrido
MuleSoft roda em nuvem (CloudHub) ou on-premise (Runtime Fabric), permitindo que o broker do dado sensível fique dentro do data center Dataprev quando necessário.
3.5 Onde a IA cabe (e onde não cabe) Prelúdio da Parte 5
Nem tudo é caso de agente. O princípio que separa IA de execução: Agentforce onde há linguagem natural, julgamento assistido e volume de atendimento; automação determinística (Flow, Apex, MuleSoft) onde há regra fixa, transação financeira e conformidade legal; analytics (Data Cloud, Tableau) onde há padrão a detectar para um humano decidir.
3.6 Residência de dados: como endereçar o "maior desafio técnico" Restrição
Rafael classificou a arquitetura de dados como o maior desafio, "não pela complexidade, mas por decidir como será". A Salesforce tem caminho comprovado, inclusive já vivido no "serviço na ponta".
| Camada de dado | Onde reside | Racional |
|---|---|---|
| Processo, metadados, regras, casos | Hyperforce Brasil (AWS SP) | Residência nacional em nuvem, confirmada pelo próprio Nelson na reunião |
| Dado ultrassensível bruto (CPF, transações) | Oracle on-premise (data center Dataprev) | Padrão já adotado no serviço na ponta (CDP Oracle) |
| Broker de integração do dado sensível | MuleSoft Runtime Fabric on-prem | Mantém o tráfego crítico dentro do perímetro Dataprev |
| Analytics de monitoramento | CDP Oracle on-premise (reuso) · Data Cloud opcional para ativação/segmentação | Analisa padrões sem duplicar CDP nem expor identificadores diretos (ver decisão 6) |
Como comprovar soberania de dados ao MTE Compliance
O MTE precisa de evidência em três camadas: arquitetural, contratual e certificatória. A semente de Agentforce discutida na oficina (FAQ informacional no portal, web primeiro) não entra sem o ateste do time de produtos/licenças DTP sobre processamento fora do Brasil. Agente transacional (WhatsApp) fica para depois, pelos mesmos temas de soberania já conhecidos em Serviço na Ponta.
| Componente | Dado viaja para fora do Brasil? | Evidência |
|---|---|---|
| Salesforce Platform / Service Cloud / Experience Cloud | Não · Hyperforce Brasil (AWS SP) | Confirmado na transcrição 01:17:39 + DPA contratual |
| MuleSoft Runtime Fabric on-prem | Não · perímetro Dataprev | Arquitetura de runtime local |
| Oracle CDP on-premise | Não · data center Dataprev | Infraestrutura própria da estatal |
| Agentforce informacional (FAQ no portal) | Ateste pendente | Semente plantada na oficina (04/09). Web primeiro. Avanço condicionado ao ateste de produtos/licenças DTP. |
| Agentforce transacional / WhatsApp | Puxa soberania | Projeção posterior. Mesmos temas de Serviço na Ponta. Fora da Fase 1. |
📄 Evidência contratual
DPA (Data Processing Addendum) — compromisso contratual da Salesforce sobre onde os dados são processados e armazenados, incluindo subprocessadores autorizados e regiões.
DRO (Data Residency Option) — adendo que garante formalmente que os dados em repouso ficam na região contratada (Brasil). Solicitar via time de Contratos/Legal da Salesforce para incluir no contrato do PAT.
🏅 Certificações aplicáveis
ISO 27001 · segurança da informação
ISO 27018 · proteção de dados pessoais em nuvem (diretamente relevante para LGPD)
SOC 2 Type II · controles auditados por terceiros
Relatórios disponíveis via Salesforce Trust Center (trust.salesforce.com). Compartilhamento formal exige NDA — padrão em contratos de governo.
- Solicitar ao AE (Fernanda Pacheco) o DPA vigente e verificar se o contrato já inclui DRO.
- Obter o ateste do time de produtos/licenças DTP sobre processamento fora do Brasil, condição para a semente de Agentforce no portal.
- Confirmar a instância exata da org Dataprev (ex.:
brazilsouth) em Setup > Company Information ou com o Customer Success. - Preparar um diagrama de fluxo de dados com fronteiras Brasil/exterior explícitas para instruir o DPIA/LGPD da Dataprev.
- Confirmar que nenhuma feature Einstein (nem AI básico, como Einstein Search ou Einstein Scoring) está habilitada sem o ateste, porque mesmo Einstein não-Agentforce pode enviar dados para inferência fora do BR se ativado.
🎯 Síntese técnica da Parte 3
A solução se apoia em produtos Salesforce individualizados: Salesforce Platform + Service Cloud como núcleo (modelo de dados, casos de credenciamento e fiscalização, motor de regras nativo em Flow/Apex/Custom Metadata), Experience Cloud (portais), OmniStudio (wizards low-code), MuleSoft (integração, mock e API management, o caminho crítico do prazo), Data Cloud + Tableau (monitoramento) e Agentforce (suporte e fiscalização assistida), tudo sobre Hyperforce Brasil com guarda on-premise do dado crítico. Em vez do bundle Public Sector Solutions, cada produto entra pela aderência ao caso, o que reduz custo e risco de execução dentro dos marcos de setembro e novembro.
4.1 Princípios que guiam a arquitetura Drivers
Além da soberania de dados e do desacoplamento de integração já estabelecidos como tese técnica na Parte 3 (seção 3.1), o desenho responde a duas forças adicionais que definem o dimensionamento e o cronograma.
⏱️ Prazo agressivo
Homologação em set/2026 e produção em nov/2026 exigem baixo código (OmniStudio, Flow) e mock de integrações desde o dia 1.
📈 Escala
~1 milhão de estabelecimentos, ~600 facilitadoras por API (certificado digital CNPJ) e beneficiárias autenticadas via gov.br Prata/Ouro. Monitoramento a posteriori de até 30M transações/dia.
4.2 Diagrama de arquitetura macro (interativo) Visão animada
Diagrama navegável no estilo de ferramenta de arquitetura, desenhado na leitura BSA anterior à oficina. A baseline oficial de 04/SET está na seção 4.7 (diagrama da oficina) e os dois caminhos de folha na 4.8. Selecione um fluxo para ver os dados percorrerem a plataforma.
- CDP de Monitoramento passa a reusar o Oracle CDP on-prem; Data Cloud fica opcional, para evitar CDP duplicado. (decisão 6)
- Marketplace / leilão em OmniStudio + LWC, com o motor de leilão em MuleSoft para suportar escala e concorrência. (decisões 2 e 4)
- MuleSoft permanece como barramento, mas o reuso do WSO2 existente entra na pauta do discovery. (decisão 5)
- Residência híbrida (nuvem nacional + on-premise) e o motor de regras nativo (Flow + Apex + Custom Metadata) para o split financeiro mantidos como decisões de alta confiança.
4.2.1 Entendimento de cada bloco da arquitetura Glossário técnico
O que é cada componente do diagrama, o que ele faz e por que ele existe nesta solução do PAT. Organizado pelas mesmas raias (swimlanes) do desenho.
Raia 1 Canais & Experiência
A porta de entrada de cada ator. É onde as pessoas interagem; nenhum dado sensível é processado aqui, apenas capturado ou exibido.
| Bloco | O que é | Papel na solução do PAT |
|---|---|---|
| 🏢 Portal Beneficiária | Site autenticado (Experience Cloud / LWR) com login GOV.BR Prata/Ouro. e-MAG 3.1 / WCAG 2.1 AA. | Empresa cria cotações (seleção manual), contratos e envia a folha. Usa procuração digital (GovID) para representar o CNPJ. |
| 🛒 Portal Estabelecimento | Site autenticado via GOV.BR Prata/Ouro, com seletor de CNPJ. | Estabelecimento (~1M) faz o pré-cadastro para ser credenciado. Estados: ATIVO / INATIVO / CANCELADO / banido. |
| 🖥️ Console MTE | Console de supervisão e fiscalização, com SSO institucional / GERID. | Fiscal e gestor do MTE acompanham o programa, configuram CNAEs/regras e disparam auditoria. |
| 💬 WhatsApp / Web chat | Canal conversacional servido pelo Agentforce. | Suporte informacional e transacional (dúvidas do programa, status de cotação/folha) sem precisar acessar o portal. |
| 📊 Painel MTE | Dashboards em Tableau / CRM Analytics. | Dá ao Ministério a visibilidade de mercado que ele nunca teve: taxas, contratos, transações, fiscalização. |
| 📱 CTPS Digital | App oficial do trabalhador (Dataprev). | Recebe a notificação de previsão de crédito, no modelo "estilo FGTS". Só aviso, sem gestão de saldo. |
Raia 2 Aplicação Salesforce (Salesforce Platform + Service Cloud)
O coração funcional do programa, montado com produtos Salesforce individualizados sobre a Plataforma, rodando na nuvem nacional (Hyperforce Brasil).
| Bloco | O que é | Papel na solução do PAT |
|---|---|---|
| ⚖️ Cotação e Contratação | Módulo de cotação. No diagrama da oficina: seleção manual. | A tese de leilão da pré-venda precisa ser confirmada. O desenho de 04/SET não fala em leilão, fala em seleção manual. |
| 🏪 Credenciamento | Gestão de casos no Service Cloud + Flow Orchestration + Aprovações. | Cria a base nacional unificada de estabelecimentos e o workflow de aprovação/descredenciamento pela facilitadora. |
| 💰 Folha e Financeiro | Orquestração de folha, boleto/NF e trilho de pagamento. | Dois caminhos em aberto (seção 4.8). Nuclea sem liquidação na Fase 1. Shield criptografa a folha antes de gravar. |
| ⚙️ Config MTE | Parametrização do programa. | CNAEs, regras e trilho de pagamento. Módulo próprio no diagrama da oficina. |
| 🛡️ Monitoramento / Casos | Gestão de casos de fiscalização. | Transforma anomalias detectadas em casos rastreáveis para o MTE agir a posteriori. |
| 🤖 Agentforce (Atlas) | Motor de agentes de IA da Salesforce. | Atende nos canais e atua como copiloto de fiscalização, triando anomalias. Sempre com humano no loop nas decisões. |
Raia 2b Regras & Automação
A camada que garante que tudo aconteça de forma exata, versionada e auditável. É aqui que mora a conformidade legal.
| Bloco | O que é | Papel na solução do PAT |
|---|---|---|
| 🧮 Motor de regras (Flow + Apex) | Regras nativas da Plataforma, com parâmetros versionados em Custom Metadata Types. | Guarda a regra do split (percentual MTE × facilitadora) e as elegibilidades. Atende ao requisito de que "a lógica fica na plataforma do MTE", sem depender do licenciamento Industries (BRE fica como upgrade opcional). |
| 🔀 Flow · máquina de estado | Automação de processos da Salesforce. | Controla os ciclos de vida: estados do leilão, do credenciamento e do processamento da folha. |
| 🧩 OmniStudio | Ferramenta low-code (DataRaptor, Integration Procedures, OmniScript). | Monta as telas guiadas e trata os arquivos de folha. Acelera a entrega dentro do prazo apertado. |
| 🔏 Shield | Platform Encryption + Field Audit Trail. | Criptografa antes de gravar (folha) e mantém trilha de campo. Confirmado no diagrama da oficina 04/SET. |
Raia 3 Camada de Dados
Onde a informação repousa. É aqui que a fronteira de residência de dados é respeitada.
| Bloco | O que é | Papel na solução do PAT |
|---|---|---|
| 🗄️ CDP de Monitoramento | Base analítica de transações. Decisão: reusar o CDP Oracle on-prem; Data Cloud apenas se houver necessidade de ativação/segmentação nativa (evita CDP duplicado). | Ingere as transações das facilitadoras (tokenizadas) e alimenta o monitoramento e a detecção de anomalias. (ver decisão 6) |
| 📦 Objetos da Plataforma | Modelo de dados transacional em custom objects da Salesforce Platform. | Armazena cotações, contratos e credenciamentos, os registros operacionais do dia a dia. |
| 🔐 Oracle on-premise | Banco no data center da Dataprev. | Guarda o dado ultrassensível bruto (CPF, transações). Fica fora da nuvem por exigência de soberania. Padrão já usado no "serviço na ponta". |
Raia 4 Integração (MuleSoft Anypoint)
O barramento único que conecta a plataforma a todos os sistemas externos. É o componente que determina o prazo do projeto.
| Função | O que é | Papel na solução do PAT |
|---|---|---|
| 🔌 API Gateway | Porta de entrada gerenciada de APIs. Decisão: avaliar no discovery o reuso do WSO2 já existente na Dataprev antes de padronizar tudo no MuleSoft. | Autentica, limita taxa e controla a visibilidade: cada facilitadora só enxerga os dados dos contratos que fechou. (ver decisão 5) |
| 🔗 API-led (System / Process / Experience) | Padrão de camadas de integração. | Isola cada integração; trocar um mock pela API real não afeta o resto da solução. |
| 🧪 Mocking | Simulação de APIs ainda inexistentes. | Permite construir contra o Novo PAT simulado até ele ficar pronto. Destrava o marco de setembro. |
| 🏠 Runtime Fabric on-prem | Motor MuleSoft rodando no data center Dataprev. | Mantém o tráfego do dado sensível dentro do perímetro on-premise. |
| 📜 Contrato de API da oficina | OpenAPI, erro RFC 9110, W3C Trace Context, filas/vazão, retry + DLQ, cert/VPN. | Padrão que já nasceu no diagrama de 04/SET. Histórias de Mule que não citarem isso nascem incompletas. CPF tokenizado, dado sensível resolvido só no perímetro. |
Raia 5 Sistemas & Parceiros externos
Sistemas que a plataforma consome ou alimenta, mas que não são construídos por nós.
| Bloco | O que é | Papel na solução do PAT |
|---|---|---|
| 🏛️ Novo PAT (MTE) | Sistema de adesão do Ministério (feito pela DTI do MTE), com GovID e procuração digital. | Fonte da verdade sobre quem está ativo. Integração crítica e imatura (por isso o mock). |
| 🔑 GOV.BR / GERID | Identidade digital: GOV.BR Prata/Ouro para beneficiárias e estabelecimentos; GERID para os usuários do MTE. | Autentica os portais e fornece a procuração digital (vínculos empresa × CPF). |
| 🧾 Receita Federal / SERPRO | Consulta de CNPJ e CNAE. | Alimenta credenciamento e Config MTE. Sistema externo consumido, não desenvolvido. |
| 🏦 Gateway / Nuclea | Trilho de pagamento. | Sem liquidação na Fase 1. O marketplace registra o trilho; não executa split/custódia nesta fase. |
| 📄 eSocial · CTPS Digital | Base de vínculos e app do trabalhador. | Confronto de folha no eSocial e notificação de crédito programado + data prevista na CTPS, só depois da confirmação de pagamento. |
| 🏢 Facilitadoras (~600) | Operadoras de VA/VR, via API com certificado digital CNPJ. Sem portal. | Processam folha, credenciam estabelecimentos e reportam transações. Volume da oficina: ~600. |
| 💳 Adquirente (J05) | Rede de captura no PDV. Consulta credenciamento via API. | Persona própria no diagrama da oficina. Consulta se o estabelecimento está ATIVO antes da transação. |
| 🗃️ CNIS PJ/PF · SDC | Fontes de dados sociais e corporativos da Dataprev (CNIS = Cadastro Nacional de Informações Sociais). | Enriquecem e validam cadastros com dados de empregadores (PJ), trabalhadores (PF) e dados estruturados de UF/municípios (SDC). |
4.2.2 Revisão crítica das decisões de arquitetura Cada escolha sob escrutínio
Nenhuma escolha tecnológica é óbvia. Aqui cada bloco do diagrama é desafiado: o que foi proposto, quais as alternativas, o trade-off e o veredito de BSA. Esta seção refina (e em alguns pontos ajusta) o desenho inicial à luz do contexto real da Dataprev.
Núcleo em Salesforce Platform (custom objects + Flow + Apex) + Service Cloud (casos de credenciamento e fiscalização), somando produtos individuais onde agregam.
Bundle PSS (Licensing, Permitting & Inspections, BRE, Action Plans); plataforma 100% custom (Heroku).
PSS entregaria credenciamento "empacotado", mas traz licenciamento Industries e objetos gerenciados que o PAT não usa por inteiro; e o leilão não é padrão nativo de PSS. Produtos individuais exigem modelar o domínio, porém dão controle total.
Compor produtos individualizados (Platform + Service Cloud + Experience Cloud + …). Aderência maior ao caso, custo proporcional ao uso e liberdade para a arquitetura híbrida de dados. PSS fica como caminho alternativo caso o cliente já tenha a suite.
OmniStudio (OmniScript + FlexCards) para as jornadas de cotação e credenciamento.
Flow (Screen Flow) para processos simples; LWC para UX sob medida e alta performance.
OmniStudio acelera wizards com ramificação (agora on Core / LWC / LWR), mas exige licença Industries e skill específico.
OmniStudio nos wizards + FlexCards; Flow na automação; LWC nos pontos públicos críticos de performance.
Experience Cloud (LWR) para portais autenticados de beneficiária e estabelecimento.
Portal custom em Heroku; arquitetura headless; app do GOV.BR como front.
São 450 mil beneficiárias e 800 mil estabelecimentos. O modelo de licença de usuário externo e a escala precisam de dimensionamento cuidadoso.
Experience Cloud LWR, mas validar modelo de licenciamento (login-based) e considerar Heroku para volumes extremos e baixo toque.
Leilão orquestrado dentro do Salesforce (objetos + regras).
Motor de leilão em MuleSoft/Heroku, com Salesforce como sistema de engajamento e registro.
Centenas de milhares de cotações e 600-700 facilitadoras em polling por API podem esbarrar em limites de plataforma.
Orquestração de alta vazão em MuleSoft/Heroku; Salesforce guarda estado, experiência e regras. Evita gargalo de governor limits.
MuleSoft Anypoint como barramento único (API management + mocking).
Reuso do WSO2, citado pela própria Dataprev na reunião; ESB existente do órgão.
MuleSoft acelera o lado Salesforce e o mock do Novo PAT, mas somar mais uma camada de integração pode duplicar custo e governança.
MuleSoft onde a aceleração Salesforce e o mock são críticos; avaliar reuso do WSO2 para integrações internas de governo. Transcrição 01:10:55
Data Cloud para ingestão de transações e base analítica.
Reuso do CDP Oracle on-premise que a Dataprev já implantou no "serviço na ponta".
Dado sensível não pode ir para nuvem externa, e manter dois CDPs gera custo e complexidade. Risco real de duplicidade.
Reusar o CDP Oracle on-prem para o dado sensível; Data Cloud só se houver necessidade de ativação/segmentação nativa. Não duplicar CDP. Transcrição 01:16:52
Agentforce atuando no monitoramento e na fiscalização.
Detecção por regras determinísticas + modelos de ML (Einstein / Data Cloud), com agente só na triagem.
Agente é fraco como detector estatístico puro; forte como copiloto que explica e prioriza casos.
Detecção por regra/ML; Agentforce como copiloto de fiscalização (triagem, explicação, minuta). Humano no loop.
Motor de regras nativo da Plataforma: Flow para o decisionamento, Apex para o cálculo e Custom Metadata Types para os parâmetros versionados (split, tetos, elegibilidades). O banco só executa.
Business Rules Engine (BRE) do bundle Industries/PSS; regra embutida no banco público.
BRE é um motor declarativo excelente, mas depende de licenciamento Industries. Flow + Apex + Custom Metadata é declarativo, versionável (deploy rastreável) e auditável via Shield, sem essa dependência.
Motor nativo (Flow + Apex + Custom Metadata); atende ao requisito "a lógica fica na plataforma do MTE". BRE como upgrade opcional se a suite Industries for adotada. Transcrição 00:46:32
Nuvem nacional (Hyperforce Brasil) + dado sensível on-premise.
Tudo on-premise; tudo em nuvem (inviável por soberania).
Híbrido adiciona complexidade de arquitetura, mas é a única opção compatível com a governança da Dataprev.
Manter. Padrão já validado pela Dataprev no serviço na ponta. Transcrição 01:17:39
Tableau para os painéis de gestão e fiscalização do MTE.
CRM Analytics (nativo da Plataforma); dashboards do próprio Data/BI da Dataprev.
Tableau é mais rico para visualização de governo; CRMA é mais nativo e barato de embarcar.
Definir por necessidade de riqueza visual vs nativo; decisão de baixo risco, adiável para o discovery.
4.3 Fluxos de referência End-to-end
Fluxo A · Cotação e contratação (leilão)
Fluxo B · Financeiro (folha, confirmação de pagamento, notificação) Atualizado 01/set/2026
Fluxo C · Monitoramento (a posteriori)
4.4 Zonas de residência de dados Conformidade
As duas zonas aparecem explicitamente no diagrama (4.2): ☁ nuvem nacional (Hyperforce Brasil) para processo, regras, casos e analytics tokenizado, e 🏢 on-premise (Oracle no data center Dataprev) para o CPF e o dado bruto sensível, com o broker MuleSoft Runtime Fabric mantendo o tráfego crítico dentro do perímetro. O mapeamento camada a camada (com o racional de cada uma) já está detalhado na seção 3.6; o ponto de conformidade aqui é que essa separação física é o que resolve o "maior desafio técnico" da reunião sem violar a soberania de dados.
4.5 Premissas e pontos a validar em projeto Assunções
Premissas assumidas
- Novo PAT exporá APIs consumíveis, com mock até a versão real
- Banco público (BB) oferece custódia + split + Bolex/Pix
- GOV.BR fornece procuração digital (empresas por CPF)
- Facilitadoras se adaptam por obrigação regulatória
A validar em descoberta
- Swagger e maturidade de cada integração
- Volume real de cotações e transações (dimensionamento)
- Modelo exato do split e taxa do MTE
- Escopo de tokenização x guarda on-premise
- Normativo/portaria que obriga beneficiária a usar o marketplace (impacta adoção)
- Capacidade do MuleSoft compartilhado — confirmar se atende escopo PAT sem conflito com outros projetos Dataprev
- Estratégia de armazenamento de transações — Oracle vs. bucket/parquet (validar com arquiteta de dados)
- Mapa de campos por tabela para o log de negócio (3 camadas) — ver 4.6
4.6 Decisões técnicas confirmadas — 01/set/2026 Reunião Sprint 0
Sessão de trabalho MTE + Dataprev de 01/set/2026 consolidou o modelo financeiro e a estratégia de dados. As mudanças impactam diretamente os Épicos 3 (Folha/boleto), 5 (MuleSoft) e 7 (Segurança/Log) do backlog.
Decisões de arquitetura e operação
| Decisão | O que ficou definido | Impacto no backlog |
|---|---|---|
| D1 · Emissor da folha | A facilitadora (não a beneficiária) envia à plataforma: folha de benefícios, transações de venda, contratos e confirmação de pagamento. A beneficiária mantém seu processo operacional com a facilitadora sem nenhuma alteração. | Épico 3 — reescrever histórias de upload e folha |
| D2 · Boleto | A plataforma não emite boleto. Recebe apenas a confirmação de pagamento da facilitadora (extrato/baixa). Reduz o escopo de integração financeira e elimina o risco de gargalo operacional. | Épico 3 — remover geração de boleto; manter histórias de confirmação |
| D3 · Armazenamento | Oracle para folha e transações (MuleSoft abre o arquivo e grava linha a linha). Bucket/object storage apenas para arquivo histórico. Facilita integração com Data Lake e analytics posteriores sem explosão de arquivos CSV avulsos. | Épico 5 / Épico 8 — estratégia de ingestão de dados |
| D4 · Dois modelos de troca | Convivem: (a) base-a-base em tempo real (réplica estruturada), para dados transacionais; (b) arquivos, para folha e transações — MuleSoft abre e grava no Oracle com tabela de metadados de controle. | Épico 5 — detalhar ambos os fluxos no backlog |
| D5 · Notificação CTPS | CTPS notificado somente após confirmação de pagamento pela facilitadora. Delay aceito — modelo de fiscalização a posteriori. Notificação linha a linha por CPF (não agregada). | Épico 3 — atualizar critérios de aceite da notificação CTPS |
| D6 · Mule mínimo | MuleSoft deve ter mínima regra de negócio possível. Preocupação com capacidade do barramento compartilhado com outros projetos Dataprev. Transformações de negócio devem ocorrer antes de chegar ao Mule ou ser feitas no Oracle. | Épico 5 — revisar histórias de transformação e capacidade |
| D7 · Log em 3 camadas | (1) Log de negócio (Oracle): alterações por tabela, antes/depois, CPF tokenizado, papel do usuário, IP/porta de origem. (2) Log de infra/aplicação: LK/Elasticsearch (login, page view, tempo de resposta). (3) Metadados de arquivo: tabela de controle com nome, qtde. de registros, sucesso/erro por linha. | Épico 7 — separar histórias de log por camada; definir mapa de campos |
| D8 · Prioridade de sprint | Cotação (Épico 2) entra em sprint primeiro — fluxo não mudou. Épicos 3 e 5 precisam ser reformulados antes de entrar em sprint. Épico 4 (Credenciamento) também não mudou. | Todos os épicos — sequência de planejamento |
Implicações estratégicas para a proposta Salesforce
📊 Oportunidade eSocial
Apenas 6 milhões dos 22 milhões de trabalhadores beneficiados declaram no eSocial. A plataforma PAT, ao centralizar folha, contratos e transações, pode se tornar a maior fonte de verdade sobre benefícios alimentares no Brasil. Cruzamento eSocial × PAT via Einstein / Data Cloud é um diferencial de segunda fase.
🤖 Semente de Agentforce plantada na oficina
A oficina discutiu um agente informacional (FAQ) no portal, para dúvidas do programa (beneficiárias, facilitadoras e estabelecimentos). Web primeiro, atrelado ao novo portal. Agente transacional (possivelmente WhatsApp) fica como projeção posterior, porque puxa soberania. O cliente recebeu bem. Avanço depende do ateste de produtos/licenças sobre processamento fora do Brasil.
⚠️ Risco de qualidade de dados
O modelo de autodeclaração cria risco: a facilitadora envia o que declara, sem garantia de fidelidade. Oportunidade de posicionar Einstein Analytics + camada de qualidade de dados sobre o Oracle transacional como governança de segunda fase.
🔌 Capacidade MuleSoft
O time Dataprev sinalizou preocupação explícita com a capacidade do barramento MuleSoft compartilhado entre projetos. Oportunidade de endereçar expansão de licenciamento ou Runtime Fabric dedicado ao PAT como parte do escopo técnico da proposta.
- Os dois caminhos de fluxo de folha (Opção A vs Opção B). Detalhe na seção 4.8. Prazo: Review de 11/SET.
- Tensão D1: Sprint 0 disse que a facilitadora envia a folha; o diagrama da oficina mostra upload pela beneficiária.
- Tensão D2 vs Opção B: Sprint 0 disse que a plataforma não emite boleto; Opção B tem o marketplace gerando boleto.
- Cotação saiu como seleção manual no diagrama, não como leilão. Precisa confirmar se o leilão caiu ou se "manual" é só o recorte da Fase 1.
- Nuclea/Gateway sem liquidação na Fase 1: o split/custódia em banco público fica para depois.
- Normativo/portaria que obriga a beneficiária a usar o marketplace: impacta escala de adoção
- Estratégia final de armazenamento de transações: validar com arquiteta de dados (Gil)
- Modelo de governança de deploy (Salesforce + Dataprev): quem implanta em produção?
4.7 Arquitetura técnica da oficina Baseline 04/SET
Diagrama oficial apresentado na oficina e enviado ao cliente em 04/09. Ainda em definição, mas é a linha de base de arquitetura. O diagrama interativo da seção 4.2 continua como leitura BSA anterior. Onde houver conflito, este desenho da oficina prevalece até a próxima revisão de sprint.
Fonte: [MARKETPLACE PAT] Arquitetura da Solução_20260904.pdf. Material em definição, Status Report externo 04/09/2026.
Como ler o desenho, de cima para baixo
| Camada | Conteúdo da oficina | O que muda para a Salesforce |
|---|---|---|
| Personas / Jornadas | J01 Beneficiária · J02 Facilitadoras (~600) · J03 Estabelecimento (~1M) · J04 MTE Fiscal/Gestor · J05 Adquirente. Auth: gov.br Prata/Ouro para beneficiária e estabelecimento; SSO institucional / GERID para o MTE; certificado digital CNPJ na API das facilitadoras. | Facilitadora não tem portal: entra por API com certificado. Adquirente entra como persona própria (consulta de credenciamento). Volume de estabelecimento sobe de ~800 mil para ~1 milhão. |
| Camada de Experiência | Experience Cloud / LWR. Design System gov.br, e-MAG 3.1 e WCAG 2.1 AA. Portal Beneficiária (cotação, contrato, folha). Portal Estabelecimento (credenciamento, seletor CNPJ). Console MTE (supervisão, fiscalização). | Acessibilidade deixa de ser "bom ter": e-MAG 3.1 / WCAG 2.1 AA entra como requisito do front. FAQ de Agentforce, se avançar, vive neste portal (web primeiro). |
| Salesforce Core | Shield com Platform Encryption e Field Audit Trail. Cinco módulos: Cotação e Contratação (seleção manual), Folha e Financeiro (boleto/NF), Credenciamento com estados ATIVO / INATIVO / CANCELADO / banido, Monitoramento/Ingestão a posteriori até 30M transações/dia, Config MTE (CNAEs, regras, trilho de pagamento). | Shield não é só Event Monitoring: criptografia de plataforma e trilha de campo entram no núcleo. Config MTE vira módulo próprio. Cotação como seleção manual precisa ser confirmada contra a tese de leilão da pré-venda. |
| MuleSoft API-led | Perímetro soberano Dataprev, on-prem. OpenAPI, erro RFC 9110, W3C Trace Context, filas e vazão, retry + DLQ, acesso por certificado/VPN. Tokenização de CPF. Dado sensível resolvido só no perímetro. | Contrato de integração ganha padrão (OpenAPI + RFC 9110 + Trace Context). DLQ e filas viram critério de aceite das histórias de Mule. CPF tokenizado reforça a tese de soberania. |
| Migração e carga inicial | Carga em 18/10: staging, qualidade mínima, dedup por CNPJ, reconciliação. Carga reconciliada alimenta o Core. | 18/10 é marco de dados, não só de software. Sem qualidade mínima e dedup, o Go Live de 15/NOV opera sobre base suja. |
| Sistemas externos | Consumidos, não desenvolvidos: Novo PAT / gov.br / GovID (procuração digital e vínculos); Receita Federal / SERPRO (CNPJ, CNAE); eSocial e CTPS Digital (confronto de folha e notificação); Gateway / Nuclea sem liquidação na Fase 1. | A Fase 1 não liquida. O trilho de pagamento existe como registro, não como split em banco. Isso alivia prazo e muda o Épico financeiro. |
| Infraestrutura analítica DTP | Data Lake Dataprev com SLAs por classe e retenção de 5+ anos. Tableau com painéis por audiência após 15/11. Disponibilização via Anexo III. Linha de auditoria pontilhada até o Console MTE. | Confirma a leitura da Marina: Tableau permanece, mas entra depois do Go Live. Data Cloud continua fora desta fase. Retenção de 5+ anos é requisito de dado, não de produto Salesforce. |
Padrões de integração que já nasceram como critério de aceite
Esses padrões estão no próprio diagrama. Histórias de MuleSoft que não citarem OpenAPI, código de erro, rastreio e DLQ vão nascer incompletas.
4.8 Os dois caminhos de fluxo de folha Sem decisão
A oficina apresentou dois desenhos. Rafa foi explícito no report externo: ainda não há decisão. A escolha precisa entrar no Comitê de 08/SET e no posicionamento DTP/MTE até a Review de 11/SET. Os dois começam iguais (beneficiária faz upload da folha em layout único nacional, portal ou API; marketplace recebe, valida e o Shield criptografa antes de gravar) e divergem a partir de quem gera o boleto.
Opção A · Facilitadora gera o boleto Mais perto da Sprint 0
- Beneficiária faz upload da folha (layout único nacional, portal ou API).
- Marketplace recebe e valida. Shield criptografa antes de gravar.
- Marketplace disponibiliza a folha à facilitadora (polling/API).
- Facilitadora processa a folha e gera o boleto.
- Facilitadora envia o boleto.
- Beneficiária acessa o boleto e paga fora da plataforma.
- Facilitadora confirma o pagamento e envia a Nota Fiscal.
- Marketplace registra a NF e o trilho de pagamento.
- Marketplace notifica a CTPS: crédito programado + data prevista.
Por que pesa: a plataforma não emite boleto, alinhado à decisão D2 da Sprint 0. Pagamento nunca entra no Salesforce. Risco operacional fica na facilitadora.
Opção B · Marketplace gera o boleto Tensão com D2
- Beneficiária faz upload da folha (layout único nacional, portal ou API).
- Marketplace recebe e valida. Shield criptografa antes de gravar.
- Marketplace processa a folha e gera o boleto.
- Marketplace envia o boleto.
- Facilitadora recebe e armazena o boleto.
- Beneficiária acessa o boleto e paga fora ou dentro da plataforma.
- Facilitadora confirma o pagamento e envia a Nota Fiscal.
- Facilitadora envia folha, NF e confirmação de pagamento, consolidados de todos os beneficiários.
- Marketplace registra e armazena o trilho de pagamento e notifica a CTPS.
Por que pesa: a plataforma emite boleto (choca com D2) e pode receber pagamento interno. A facilitadora devolve um consolidado, o que muda o modelo de API e o volume de arquivo.
| Opção A | Opção B | |
|---|---|---|
| Quem gera o boleto | Facilitadora | Marketplace (Salesforce) |
| Onde a beneficiária paga | Sempre fora da plataforma | Fora ou dentro da plataforma |
| O que a facilitadora devolve | Confirmação de pagamento + NF, por operação | Folha + NF + confirmação, consolidado de todos os beneficiários |
| Papel do Marketplace | Valida, disponibiliza (polling/API), registra trilho, notifica CTPS | Valida, gera boleto, armazena, registra trilho, notifica CTPS |
| Aderência à Sprint 0 | Alinha com D2 (plataforma não emite boleto) | Choca com D2. Amplia o Épico 3. |
| Risco de prazo | Menor no Salesforce, maior na operação da facilitadora | Maior no Salesforce (emissão de boleto + possível pagamento interno) |
Fonte: [MARKETPLACE PAT] Arquitetura + Folha Opcoes_20260904.pdf, enviado junto com o Status Report externo de 04/09/2026.
🎯 Síntese da arquitetura
A baseline da oficina (04/SET) é o desenho que vale agora: Experience Cloud LWR com e-MAG 3.1 / WCAG 2.1 AA, Salesforce Core com Shield (Platform Encryption + Field Audit Trail), MuleSoft no perímetro soberano Dataprev, carga inicial em 18/10, Nuclea sem liquidação na Fase 1 e Tableau depois de 15/11. O maior nó aberto é o fluxo de folha (Opção A vs Opção B). Até essa escolha, o Épico 3 não fecha. O dado crítico permanece on-premise, com CPF tokenizado e resolvido só no perímetro Dataprev.
5.1 Critério de decisão: quando usar agente Regra
A escolha entre Agentforce e automação determinística não é preferência, é adequação. O critério orienta todo o catálogo abaixo.
🤖 Agentforce
Linguagem natural, dúvida aberta, julgamento assistido, alto volume de atendimento, triagem. Tolera resposta probabilística com humano no loop.
⚙️ Determinístico
Regra fixa, transação financeira, máquina de estado, conformidade legal. Exige resultado exato e auditável. Flow, Apex, MuleSoft.
📊 Analytics
Visão agregada, tendência, detecção de padrão para humano decidir. Tableau / Data Cloud. Alimenta o agente, não o substitui.
5.2 Casos de uso COM Agentforce IA generativa + ação
Onde o agente cria valor real. A oficina de Florianópolis (04/09) confirmou o caminho da Fase 1: UC-01 como FAQ informacional no portal, web primeiro. UC-02 (transacional/WhatsApp) fica como projeção posterior, porque puxa soberania.
FAQ do programa no portal, para dúvidas de beneficiárias, facilitadoras e estabelecimentos. Caso clássico de agente informacional. Web primeiro, atrelado ao novo portal.
"Como está minha cotação?", "Minha folha foi processada?", "Quando cai meu repasse?" com resposta contextual. Possivelmente WhatsApp, em fase posterior.
Resume casos de anomalia, explica por que uma transação é suspeita, sugere priorização e minuta de notificação administrativa.
Orienta o estabelecimento sobre documentos exigidos, valida completude e explica o status ("pendente", "em análise pela facilitadora").
Guia a integração por API, aponta contratos/specs, testa conectividade e responde dúvidas técnicas de integração.
Responde dúvidas sobre a previsão de crédito ("por que ainda não recebi?", "qual empresa/facilitadora?").
5.3 Casos de uso SEM Agentforce Determinístico / Analytics
O núcleo transacional e de conformidade. Aqui o agente não cabe: exige resultado exato, auditável e legalmente defensável.
Beneficiária cria e publica a necessidade; máquina de estado controla o ciclo do leilão.
Flow + Apex calculam o percentual (MTE x facilitadora), com parâmetros em Custom Metadata, e MuleSoft comanda o banco custódia. Trilha via Shield.
Upload em layout único, parsing e roteamento por contrato à facilitadora; geração de boleto (Bolex/Pix).
Pré-cadastro GOV.BR, verificações (CNPJ, CNAE, fiscal) e workflow de aprovação/descredenciamento pela facilitadora via API.
Checa se beneficiária/facilitadora estão ativas antes de operar no marketplace.
Evento de folha dispara aviso de previsão de crédito ao trabalhador. Sem gestão de saldo.
CDP Oracle on-prem recebe as transações (tokenizadas) e roda regras de anomalia (horário, valor, item fora do rol). Data Cloud opcional para ativação/segmentação nativa.
Volumes, taxas de mercado, contratos, estabelecimentos, indicadores de fiscalização.
5.4 Jornadas end-to-end personificadas Interativo
Cada ator citado pela Dataprev virou uma persona com sua jornada completa: o que a pessoa vive de um lado, o que o sistema faz do outro. Escolha uma persona e clique em cada passo para ver o detalhe (quem faz o quê, qual caso de uso e quais componentes Salesforce entram).
Entra no portal e escolhe a empresa que representa, usando a procuração digital do GOV.BR.
O Experience Cloud autentica via GOV.BR (prata/ouro) e o MuleSoft valida se a empresa tem adesão ativa no Novo PAT.
Preenche um formulário guiado: nº de funcionários, valor, VA/VR/misto, UF e vigência.
O OmniStudio conduz o wizard e publica a necessidade no marketplace; a máquina de estado abre o leilão.
Sem sair da tela, pergunta no chat: "Que valor devo colocar? Qual a diferença de VA e VR?"
O Agentforce responde em linguagem natural com as regras do PAT (atendimento informacional).
Vê as propostas das facilitadoras lado a lado, padronizadas e fáceis de comparar.
O marketplace coleta as respostas enviadas por API pelas facilitadoras e normaliza tudo (dinâmica de leilão).
Recebe no WhatsApp: "Chegaram 3 propostas para a sua cotação", sem precisar entrar no portal.
O agente transacional consulta o status e avisa de forma proativa.
Assina o Termo de Aceitação (checkbox) na plataforma e confirma a proposta escolhida.
Cotação__c muda para "Contratada"; CTR-xxxxxx (Contrato__c) é criado; Canais de Contratação são exibidos para formalização bilateral.
Sobe a folha uma única vez, num layout padronizado (nada de um formato por facilitadora).
DataRaptor e Integration Procedures fazem o parsing e roteiam à facilitadora; o boleto é gerado (Bolex/Pix).
Paga o boleto e acompanha o repasse; pode perguntar "quando cai?" pelo chat.
O pagamento cai na conta custódia, o motor de regras (Flow + Apex) calcula o split e o Shield registra a trilha de auditoria.
A equipe técnica pergunta a um assistente sobre endpoints, autenticação e specs da API.
O agente de onboarding aponta contratos/specs, testa a conectividade e tira dúvidas técnicas.
O sistema da facilitadora busca as cotações compatíveis com o seu perfil.
O API Gateway libera apenas os dados dos contratos que lhe cabem (visibilidade restrita por facilitadora).
Responde as cotações automaticamente e em escala.
A proposta padronizada entra no leilão via API e fica comparável para a beneficiária.
Recebe a folha roteada e devolve o boleto.
A integração processa e retorna via API; a padronização substitui o layout próprio de cada facilitadora.
Aprova, pede dados ou descredencia estabelecimentos.
O workflow de credenciamento (Service Cloud) é exposto por API e alimenta a base nacional unificada.
Envia as transações: estabelecimento, valor, data/hora e CPF.
A ingestão no CDP de monitoramento (tokenizado) alimenta a detecção de anomalias do MTE.
Entra com o GOV.BR e faz o pré-cadastro do mercado na plataforma.
O Experience Cloud cria o registro "pendente" na base nacional unificada de estabelecimentos.
"Quais documentos eu preciso? Por que está pendente?" pergunta pelo chat.
O agente orienta os documentos exigidos, valida a completude e explica o status.
Aguarda a facilitadora analisar o pedido de credenciamento.
A facilitadora consulta e aprova por API, com verificações de CNPJ, CNAE e situação fiscal.
Recebe o aviso de que está ativo e já pode aceitar os cartões.
A máquina de estado muda o credenciamento para "ativo".
Passa qualquer cartão de VA/VR na maquininha, graças à interoperabilidade.
A transação flui e é reportada ao monitoramento do programa.
Recebe em até 15 dias, com taxa limitada a 3,6% (as novas regras do Decreto).
O fluxo financeiro reflete os tetos e prazos do Decreto 12.712/2025.
Recebe na CTPS Digital: "Seu crédito de alimentação está previsto para o dia X."
Um evento da folha dispara a notificação (modelo estilo FGTS), sem gestão de saldo.
"Por que ainda não recebi? Qual empresa e facilitadora?" pergunta no app.
O agente responde com base no status (fase posterior; reuso da mensageria já operada pela Dataprev).
Compra no mercado credenciado com o cartão, em qualquer maquininha.
A interoperabilidade garante a aceitação universal dos cartões.
Usa com a segurança de que o valor é exclusivo para alimentação.
O monitoramento detecta desvios a posteriori (enforcement da lei), sem bloquear a sua compra.
Vê volumes, taxas praticadas, contratos e a rede de estabelecimentos, dados que o MTE nunca teve.
O Tableau / CRM Analytics materializa a visibilidade de mercado.
Recebe um alerta de padrão suspeito: venda de madrugada, valor atípico, item fora do rol.
Regras e ML sobre o CDP de monitoramento sinalizam a anomalia (detecção determinística, não IA generativa).
Lê um resumo pronto: por que é suspeito, a prioridade sugerida e uma minuta de notificação.
O Agentforce tria, explica e prioriza. A decisão continua com o humano.
Analisa, decide e emite a notificação administrativa.
O caso de fiscalização fica registrado e rastreável (a posteriori, sem bloquear a venda).
Acompanha a resolução e o efeito no mercado pelo painel.
O ciclo alimenta os indicadores de fiscalização e gestão do programa.
5.5 Catálogo consolidado de casos de uso Base da priorização
Este catálogo alimenta diretamente a Parte 6 (quick wins × complexidade e KPIs).
| ID | Caso de uso | Persona | Tipo | Módulo |
|---|---|---|---|---|
| UC-01 | Agente informacional do PAT | Benef/Estab/Facil | Agentforce | Transversal |
| UC-02 | Agente transacional de status | Beneficiária | Agentforce | Marketplace/Financeiro |
| UC-03 | Copiloto de fiscalização | MTE | Agentforce | Monitoramento |
| UC-04 | Assistente de credenciamento | Estabelecimento | Agentforce | Credenciamento |
| UC-05 | Onboarding da facilitadora | Facilitadora | Agentforce | Transversal |
| UC-06 | Apoio ao trabalhador | Trabalhador | Agentforce | CTPS |
| UC-07 | Publicação de cotação (leilão) | Beneficiária | Determinístico | Marketplace |
| UC-08 | Split e repasse financeiro | Sistema/MTE | Determinístico | Financeiro |
| UC-09 | Processamento de folha | Beneficiária | Determinístico | Financeiro |
| UC-10 | Credenciamento de estabelecimento | Estab/Facilitadora | Determinístico | Credenciamento |
| UC-11 | Validação de adesão (Novo PAT) | Sistema | Determinístico | Transversal |
| UC-12 | Notificação de crédito (CTPS) | Trabalhador | Determinístico | CTPS |
| UC-13 | Ingestão + detecção de anomalia | MTE | Analytics | Monitoramento |
| UC-14 | Painel de gestão do MTE | MTE | Analytics | Monitoramento |
🎯 Síntese da Parte 5
São 14 casos de uso: 6 com Agentforce (suporte e fiscalização assistida) e 8 determinísticos/analíticos (o núcleo transacional e de conformidade). O agente acompanha e orienta; o sistema executa e comprova. Nas jornadas, o toque de IA aparece nos pontos de dúvida e status, nunca na execução financeira. É esse recorte que permite ganhar percepção de inovação (UC-01, pedido do cliente) sem colocar em risco a conformidade legal do programa.
6.1 Matriz de priorização · Valor × Complexidade Quick wins
Os 14 casos de uso da Parte 5 plotados por valor de negócio (vertical) e complexidade técnica (horizontal), no estilo de um quadrante mágico. Cada bolha é um caso de uso, com o nome fixo ao lado; a cor indica o tipo.
Quick WinsAlto valor · baixa complexidade · fazer primeiro
Apostas EstratégicasAlto valor · alta complexidade · núcleo
IncrementaisValor médio · baixa complexidade
Fase 2 / DependentesDependem de base pronta6.2 Sequenciamento por ondas (ancorado aos marcos) Roadmap
As ondas respeitam os dois marcos inegociáveis da reunião: homologação em set/2026 e produção completa em 15/nov/2026.
Onda 1 · Marco de Homologação
até fim de setembro/2026Cotação/contratação (leilão) homologado + integração com Novo PAT (com mock). Quick wins de percepção em paralelo.
Onda 2 · Marco de Produção
até 15/novembro/2026Módulo financeiro completo, credenciamento e notificação ao trabalhador. Fecha o escopo comprometido.
Onda 3 · Evolução pós go-live
a partir de dez/2026Inteligência de fiscalização e experiência ampliada, quando a base de transações já existe.
6.3 KPIs por caso de uso Medição
| UC | Caso de uso | KPI primário | Direção / meta |
|---|---|---|---|
| UC-01 | Agente informacional | Taxa de autoatendimento (deflection) · CSAT | >60% resolvido sem humano |
| UC-02 | Status transacional | % consultas resolvidas sem acessar o portal | >50% · resposta <10s |
| UC-03 | Copiloto fiscalização | Tempo de triagem de anomalia · nº fiscalizações geradas | Reduzir tempo · aumentar cobertura |
| UC-04 | Assist. credenciamento | % cadastros completos na 1ª tentativa | >80% |
| UC-05 | Onboarding facilitadora | Tempo médio de integração por API | Reduzir dias · menos tickets |
| UC-06 | Apoio ao trabalhador | CSAT · deflection na CTPS | Alta satisfação |
| UC-07 | Cotação/leilão | Nº propostas por cotação (concorrência) | >3 propostas/cotação |
| UC-08 | Split financeiro | % splits corretos · prazo de repasse | 100% corretos · ≤15 dias |
| UC-09 | Processamento de folha | % folhas em layout único · erros | 100% padronizado · erros ~0 |
| UC-10 | Credenciamento | Estabelecimentos na base unificada · tempo | Crescer base · reduzir tempo |
| UC-11 | Validação Novo PAT | Disponibilidade da validação | >99% · 0 operação irregular |
| UC-12 | Notificação CTPS | Tempo folha → notificação · entrega | <24h · alta taxa de entrega |
| UC-13 | Detecção de anomalia | Nº anomalias detectadas · falsos positivos | Aumentar detecção · reduzir ruído |
| UC-14 | Painel de gestão MTE | Adoção pelo MTE · indicadores disponíveis | Uso recorrente · cobertura total |
6.4 KPIs de programa (North Star) Sucesso do MTE
Indicadores que provam que o objetivo de política pública da Parte 2 foi atingido. São a medida final de sucesso para o cliente.
6.5 Escopo Salesforce: Estratégico × Professional Services Fecho BSA
🎯 Escopo estratégico (tecnologia)
- Salesforce Platform + Service Cloud (produtos individualizados) como núcleo do programa nacional
- MuleSoft como barramento e habilitador do prazo (mock + API management)
- Agentforce como diferencial de inovação pedido pelo cliente
- Data Cloud + Tableau para a governança que o MTE nunca teve
- Modelo replicável para outros ministérios (expansão de conta)
🛠️ Escopo de implementação (PS)
- Discovery com foco em contratos de API e residência de dados
- Onda 1: leilão + Novo PAT (mock) + quick wins de IA
- Onda 2: financeiro, credenciamento e notificação
- Onda 3: monitoramento inteligente e experiência ampliada
- Squad híbrido reaproveitando ativos do serviço na ponta
🎯 Síntese da Parte 6 · fecho do raciocínio
A priorização mostra que o núcleo pesado coincide com os marcos obrigatórios, então a estratégia vencedora é blindar essas apostas estratégicas com MuleSoft (mock) e, em paralelo, entregar quick wins de IA e visibilidade (UC-01, UC-14) que geram percepção de valor imediata. Os KPIs conectam cada caso de uso ao North Star do MTE: transparência, conformidade de taxa e prazo, base unificada e fiscalização efetiva. É assim que a Salesforce sai de fornecedora de tecnologia para parceira da governança de um mercado de R$ 150-200 bilhões.
Do Marketplace à Inteligência de Política Pública
O MTE não quer apenas modernizar o PAT — quer enxergar o trabalhador brasileiro com granularidade nunca vista antes. A plataforma que construímos hoje é a fundação para isso.
🔭 A visão do MTE — granularidade transacional Estratégico
Raimundo (MTE) deixou claro na reunião: o objetivo não é só ter um marketplace funcional. É chegar a um nível de granularidade onde o governo consegue ver cada transação individual do PAT — quem comprou, o quê, onde, em qual estabelecimento, processado por qual facilitadora e adquirente — e cruzar isso com dados da Receita Federal, CNPJ e CNAE dos estabelecimentos.
O que essa granularidade permite ao MTE
📊 Inteligência nutricional e de consumo
- "X% dos trabalhadores de São Paulo consomem X tipos de alimentos"
- Mapeamento regional de padrões alimentares da classe trabalhadora
- Insumo para políticas de saúde pública do trabalhador
- Identificação de desertos alimentares por UF ou município
🔍 Fiscalização e conformidade
- Detecção de estabelecimentos com CNAE incompatível com alimentação
- Identificação de desvio de uso do benefício (compras não alimentares)
- Rastreamento de empresas com irregularidades nas novas regras do Decreto 12.712
- Cruzamento facilitadora × adquirente × taxa praticada
🏢 Inteligência de mercado
- Concentração de mercado por facilitadora e adquirente
- Cobertura de estabelecimentos credenciados por região
- Análise de repasse: tempo real entre facilitadora e estabelecimento
- Impacto da interoperabilidade por bandeira
🎯 Política pública baseada em evidência
- Benchmarks regionais para políticas de alimentação saudável no trabalho
- Avaliação de impacto do Decreto 12.712 com dados reais
- Subsídio para revisões do próprio programa PAT
- Transparência pública: dados anonimizados para pesquisadores
🗺️ A jornada do dado — da transação à política pública
Cada compra com vale-alimentação percorre um caminho longo antes de chegar ao MTE. A plataforma que estamos construindo é a infraestrutura que captura e conecta cada ponto desse caminho.
Hoje o MTE não tem visibilidade da maioria desses dados. A plataforma Salesforce — Data Cloud como hub, MuleSoft como barramento, Tableau como camada analítica — é exatamente o que fecha essa cadeia.
🧩 Como o portfólio Salesforce habilita essa visão
| Necessidade do MTE | Produto Salesforce | Como resolve |
|---|---|---|
| Centralizar transações de 600-700 facilitadoras/adquirentes | MuleSoft Anypoint Platform | API gateway unificado — cada facilitadora se integra uma vez, o MTE consome tudo em um lugar |
| Criar o Citizen/Worker 360 — trabalhador como hub | Data Cloud (Identity Resolution) | CPF do trabalhador conecta e-Social, CNIS, Receita Federal e dados PAT em um perfil unificado |
| Cruzar CNPJ/CNAE do estabelecimento com a transação | Data Cloud + MuleSoft (Receita Federal API) | Cada transação enriquecida com dados cadastrais do estabelecimento em tempo real |
| Detectar anomalias — uso fora do escopo, desvios | Agentforce + Einstein (anomaly detection) | Modelos treinados em padrões de consumo PAT identificam transações atípicas automaticamente |
| Visualizar padrões de consumo por região, setor, UF | Tableau (Pulse + Analytics) | Dashboards em linguagem natural — "% trabalhadores SP que consomem X" vira um clique no painel |
| Garantir LGPD e soberania de dados | Einstein Trust Layer + Hyperforce Brasil | Dados anonimizados antes de qualquer análise; toda infraestrutura em AWS São Paulo |
📈 Os 3 horizontes — da plataforma ao observatório de política pública
H1 · Marketplace operante (2026)
Facilitadoras integradas via MuleSoft. Transações fluindo pela plataforma. Agente auxiliando empresa e analista MTE. Copiloto de fiscalização com acesso a dados reais.
H2 · Inteligência transacional (2027)
Data Cloud consolidando transações cruzadas com CNPJ/CNAE. Primeiros dashboards Tableau com padrões de consumo por região. Einstein detectando anomalias em escala.
H3 · Observatório de Política Pública (2028+)
Granularidade plena: trabalhador × refeição × estabelecimento × facilitadora × adquirente. Publicação de dados anonimizados para pesquisadores. Insumo para revisão do marco regulatório PAT.
🔗 Por que o MVP de hoje importa para a visão futura
A tentação é tratar o Marketplace como um projeto isolado de compliance. O Raimundo sinalizou que não é: o MTE quer a plataforma como infraestrutura de dados de longo prazo. Isso muda o que decidimos no MVP.
O que comunicar ao MTE agora
O Salesforce pode entregar o H1 (Marketplace operante) como projeto. Mas se o MTE confirmar que quer o H3 (Observatório), o escopo do H1 muda: em vez de integrar cada facilitadora de forma ad-hoc, construímos desde o início com o padrão de dados que o Data Cloud vai precisar. Isso é conversa estratégica para os diretores Antônio Jaime e Flávio Ronerson — não para o time técnico.
🎯 Síntese · o que essa visão muda no posicionamento Salesforce
O PAT não é apenas um mercado de R$150-200bi para modernizar. É o maior dataset de comportamento de consumo alimentar da classe trabalhadora brasileira. O MTE quer usar isso para fazer política pública baseada em evidência. O Salesforce, via Data Cloud + MuleSoft + Tableau, é a única plataforma que transforma transações de 21,9M trabalhadores em inteligência de governo sem precisar construir do zero. Isso eleva a conversa de "produto de compliance" para "infraestrutura estratégica do MTE".
📚 Fontes & Referências
Fonte primária
- Transcrição da reunião [DATAPREV+SALESFORCE] DPS/SUTF/DEBT, Apresentação de demanda e avaliação de aderência, 21/07/2026 (Notes by Gemini). Timestamps citados ao longo do documento.
- Status Report Semanal Interno [DTP - MARKETPLACE PAT], Rafael Roquette, 12/09/2026. Fonte operacional da Sprint 1 (6 de 7 histórias, Slack External, Nuclea fora do SPB, Sprint 2, alocações, riscos de VPN e folha).
- Status Report Semanal Externo [MARKETPLACE PAT] Sprint 1 (08/SET a 11/SET), Rafael Roquette, 12/09/2026. Cascas Gov.br dos três portais, CI/CD, pedidos à DTP/MTE (VPN 16/SET, folha 16/SET, arquivos e CTPS 18/SET), marcos 25/SET, 30/SET, 06/NOV e 15/NOV.
- Ata [MARKETPLACE PAT] Comitê Executivo, Rafael Roquette, 08/09/2026. Rito semanal, alerta de Jaime sobre o MVP de 30/SET, acessos MuleSoft e folha A vs B ainda abertos.
- Deck [MARKETPLACE PAT] Comitê Executivo do Projeto_20260915, Rafael Roquette, 15/09/2026. Status da Sprint 2, alocação e riscos para o comitê de hoje.
- Canal Slack #dtp-marketplace-pat-equipe-projeto (C0C15BYDMSL), 08 a 15/09/2026. Autenticação (OIDC vs SAML/JIT), VPN, backlog de HUs, Lucid, Squad 1.
- Time de arquitetura e delivery (Nelson Stebulaitis Filho, Rafael Roquette, Eric Gasparotto), 15/09/2026. Confirmação do backbone: teto versus discovery, Folha Cenário A em 14/SET, 30M e 50M como a mesma família, Community Login 1,2 milhão já contratada, transação no escopo para receber no Lakehouse.
- Alinhamento interno de 14 e 15/09/2026 sobre o baseline de consumo da org PAT/MTE, distinta da org Dataprev, para a análise do contrato ilimitado. Transação de vale não se traduz em atendimento Agentforce.
- Eric Gasparotto, 16/09/2026, canal Slack #dataprev-petit-committee (C0AD6NBDZQS). ADR-001 (draft): Padrão de acesso a Account sob licença Customer Community Login. Community Login concede Read e Edit em Account, não Create. Contorno validado em pat-dev: LWC + Apex em System Mode + Sharing Set. Pedido de confirmação comercial de que a SKU é Login, não Plus.
- Granola: [MARKETPLACE PAT] Comitê Executivo (08/09/2026) e Funcionamento do Marketplace atual (14/09/2026, com Rodrigo Lobo e Hildegard Barbosa / DTP).
- Status Report Semanal Interno [DTP - MARKETPLACE PAT], Rafael Roquette, 04/09/2026. Fonte operacional da Semana 0 (oficina Florianópolis, oportunidades, ritos, alocações e semente de Agentforce).
- Status Report Semanal Externo [MARKETPLACE PAT] Fechamento da Oficina Inicial (31/AGO a 04/SET), Rafael Roquette, 04/09/2026. Linha de base: 11 épicos, 45 funcionalidades, 195 histórias, 4.670 story points; 9 sprints de 27/AGO a 18/DEZ; dois caminhos de fluxo de folha ainda sem decisão.
- E-mail [MARKETPLACE PAT] Ritos do projeto: Criação dos convites recorrentes, Rafael Roquette para Georges Leitão dos Santos, 03/09/2026, com resposta de Georges no mesmo dia pedindo a Fabrício Paiva os nomes DTP por rito.
- Anexo [MARKETPLACE PAT] Arquitetura da Solução_20260904.pdf. Diagrama oficial da oficina: personas, Experience Cloud/LWR, Shield (Platform Encryption + Field Audit Trail), MuleSoft on-prem, carga inicial 18/10, Nuclea sem liquidação na Fase 1, Data Lake + Tableau pós-15/11.
- Anexo [MARKETPLACE PAT] Arquitetura + Folha Opcoes_20260904.pdf. Dois caminhos de processamento da folha (Opção A: facilitadora gera o boleto; Opção B: marketplace gera o boleto). Sem decisão em 04/SET.
Marco regulatório
- Decreto nº 12.712, de 11/11/2025, Presidência da República / Normas Legais (altera Decreto 10.854/2021).
- Lei nº 6.321/1976 (cria o PAT) e Lei nº 14.442/2022 (reforma).
- Cescon Barrieu, "PAT: o que mudou com o Decreto 12.712/2025?"
- GSGA, "Novo marco do Programa de Alimentação do Trabalhador (PAT)".
- G1, "Vale-alimentação e refeição: novas regras e taxas entram em vigor" (12/02/2026).
Mercado e volumetria
- ABBT, Associação Brasileira das Empresas de Benefícios ao Trabalhador (site institucional e Parecer Econômico).
- Poder360, "Análise Econômica da Interoperabilidade e Portabilidade no Mercado de Benefícios" (01/2026).
- Bloomberg Línea, "Gigantes do mercado de vale-refeição vão ao STF contra decreto do governo".
- Gov.br / SECOM, dados de cobertura do PAT por UF.
Tecnologia Salesforce
- Salesforce Hyperforce no Brasil (região AWS South America / São Paulo) e documentação de Data Residency.
- Hyperforce Summer '26 (18 países, cobertura de Data Cloud e Agentforce; PCI Hyperforce LACA SA East 1 Brazil).
- Produtos Salesforce individualizados: Salesforce Platform (custom objects, Flow, Apex, Custom Metadata Types), Service Cloud, Experience Cloud e OmniStudio. Public Sector Solutions fica de fora de propósito. Ver seção 3.2.1 e o backbone de licenças.
- Salesforce Developer Limits and Allocations: API Request Limits (Enterprise 100.000 + 1.000 por named license; Unlimited 100.000 + 5.000; Customer Community Login = 0 chamada API; concurrent de chamada >20s = 25 em produção). Bulk API 2.0: até 150 milhões de registros ingeridos por 24h. Platform Event Allocations (Enterprise: 250 mil published/hora, 25 mil delivered/24h na alocação padrão).
- Salesforce Help, Data and Storage Resources: 10 GB de data storage por org (Enterprise/Unlimited), mais 20 MB por named user (EE) ou 120 MB (UE). Record size overview: a maior parte dos custom objects conta 2 KB por registro.
- Salesforce Help, Experience Cloud User Licenses: login-based consome 1 daily unique login; relação 1 login mensal comprado para até 20 users provisionáveis.
- Salesforce Help, User License Types for Experience Cloud Sites: Customer Community Login concede Read e Edit em Account, sem Create. Create em Account entra na Customer Community Plus. Confirmado na tabela de SKU anexada por Eric Gasparotto em 16/09/2026 (ADR-001).
- Salesforce Agentforce Pricing e Flex Credits Rate Card (31/08/2026): o consumo comercial de Agentforce é action (20 Flex Credits na ação padrão) ou conversa, conforme o modelo do contrato. Não se licencia por login de Experience Cloud. Sem série de atendimentos do Celeste neste material, não há baseline de actions para a org PAT.
- MuleSoft Anypoint Platform (API-led connectivity, API mocking, API Management, Runtime Fabric).