Knowledge base

Trato tudo em coleções desde o início: nada de SOQL/DML dentro de loops, uso maps para lookups, e handlers de trigger bulk-safe. Para volume, movo o processamento para Batchable/Queueable com chunk controlado e Database.Stateful quando preciso acumular. Consultas sempre seletivas, com os campos mínimos e SECURITY_ENFORCED.

Service / Repository (ou Selector) / TriggerHandler. A trigger não tem lógica — delega ao handler; a regra de negócio vive em service classes desacopladas e testáveis; o acesso a dados fica isolado no selector. Isso mantém cobertura de teste alta e facilita reuso entre LWC, Flows e integrações.

De cabeça: regras de validação do sistema → before triggers → validação customizada → salvamento (sem commit) → after triggers → assignment rules → auto-response → workflow (e aqui mora o perigo: field update de workflow re-dispara triggers) → processes/flows record-triggered → escalation → roll-up summary nos pais → sharing → commit → pós-commit (e-mail, async). Saber isso na prática é o que evita recursão infinita e resultado 'fantasma' em produção — por isso todo trigger meu tem controle de recursão desde o dia um.

Cobertura de 75% é o mínimo pra deploy, não é qualidade. Meus testes usam TestDataFactory e @testSetup (nunca SeeAllData), rodam cenário em massa (200 registros, não 1), têm asserts com mensagem clara, usam Test.startTest/stopTest para resetar limites e disparar async, mockam callouts com HttpCalloutMock, e cobrem o caminho negativo e o de permissão (System.runAs). Teste que não falharia se a regra quebrasse não é teste — é decoração.

Princípio do menor privilégio, sempre. OWD restritivo como base, role hierarchy pra abrir visibilidade vertical, sharing rules pra exceções bem definidas. Acesso a objeto e campo via permission sets (e permission set groups) em vez de inflar profiles — profile enxuto, quase só login e defaults. Isso deixa o acesso auditável e reversível: quando alguém muda de função, você troca o conjunto, não caça checkbox em profile gigante.

Declarativo primeiro: se um admin consegue manter a lógica amanhã sem mim, ela nasce em Flow — com governança de um record-triggered flow por objeto/evento e subflows reutilizáveis. Apex entra quando o assunto é volume com lógica complexa, controle fino de transação e erro, callouts elaborados ou regra que precisa de teste unitário de verdade. O que eu não aceito é a mesma regra viver duplicada nos dois — isso é bug agendado.

Salesforce DX com múltiplas orgs (DEV → QA → UAT → PROD) e GitHub Actions. Login via JWT OAuth (sem senha), deploy por manifest derivado da branch, quality gates que bloqueiam debug/logs esquecidos, dry-run antes do deploy real e destructive changes versionados. Deploy vira uma operação auditável e sem surpresa.

Named Credentials para credenciais fora do código, callouts HTTP encapsulados em um service reutilizável, e configuração por Custom Metadata para não hardcodar endpoints. Sincronização idempotente com campos de controle, tratamento de retry/erro e mocks nos testes. Quando o volume pede, faço a ponte assíncrona.

Motor fiscal com regras versionadas por data de vigência (effective dating), validação pré-envio na própria UI (CNPJ, IE, NCM, CFOP), e golden tests que rodam os cálculos conhecidos a cada mudança de alíquota. Emissão via gateway (Focus NFe) com certificado A1 protegido em cofre de segredos.

Row-Level Security no banco como primeira linha — o tenant nunca vê dados de outro nem por bug de aplicação. Sobre isso, RBAC granular, escopo por request e, quando o dado é sensível, privacidade por campo (não por registro). Segredos em cofre, 2FA, e trilha de auditoria.

Next.js (App Router) me dá SSR, Server Components e Server Actions para reduzir superfície de API e latência. Para domínios maiores, backend dedicado em NestJS ou Fastify com Prisma/PostgreSQL. TypeScript ponta a ponta, com um pacote de domínio compartilhado entre web, API e mobile para não duplicar tipos e regras.

Estratégia dual-model (um modelo forte para raciocínio, um rápido/barato para parse), tool-use com ferramentas de leitura bem definidas, e sempre com fallback e limites. A IA sugere; ações críticas exigem confirmação. Trato custo, latência e privacidade como requisitos, não detalhes.

Ingestão via Data Streams → os dados chegam como Data Lake Objects (DLO) e são mapeados para o modelo canônico em Data Model Objects (DMO). Sobre isso rodo Identity Resolution com regras de match (determinístico por e-mail/telefone, reconciliação por regras) para gerar o Unified Individual. Depois, Calculated Insights para métricas por perfil, segmentação e Activation para os canais. Os pontos que mais quebram: harmonização entre fontes, escolha das chaves, e os limites de refresh/latência de cada stream.

Relatórios e dashboards nativos: visão operacional sobre dados que já vivem no CRM — comece sempre por aqui, é o que o time adota mais rápido. CRM Analytics: análise histórica e avançada, múltiplas fontes estruturadas, predição com Einstein Discovery. Data Cloud: quando o problema é unificar identidade em escala, ingerir dado comportamental/streaming e ativar segmentos em quase tempo real. Na prática, projeto maduro combina os três — o erro clássico é comprar Data Cloud pra resolver problema de relatório.

CRM Analytics roda sobre datasets, não sobre objetos do Salesforce — então SOQL não se aplica ali; a linguagem é SAQL (com SOQL só na extração). Os dados chegam via Dataflows (legado) ou Data Prep Recipes (a abordagem moderna: joins, transformações e até nós de ML). A segurança se dá por security predicates e herança de sharing. Para predição embarcada, uso Einstein Discovery gerando modelos consumíveis no dashboard e via Apex.

Health Cloud estende o core com objetos clínicos (Person Account como paciente, Care Plan, Clinical/Health objects) e mapeamento FHIR/HL7 para interoperar com sistemas de saúde. No desenvolvimento, o que mais pesa é conformidade: PHI e consentimento explícito, Shield Platform Encryption para dados sensíveis, e regras de compartilhamento estritas (HIPAA/LGPD). Jornadas de care management combinam bem com OmniStudio.