Knowledge base

Everything is collection-based from the start: no SOQL/DML inside loops, maps for lookups, and bulk-safe trigger handlers. For volume, I move processing to Batchable/Queueable with controlled chunks and Database.Stateful when I need to accumulate. Queries are always selective, with the minimum fields and SECURITY_ENFORCED.

Service / Repository (or Selector) / TriggerHandler. The trigger holds no logic — it delegates to the handler; business rules live in decoupled, testable service classes; data access is isolated in selectors. That keeps test coverage high and makes reuse easy across LWC, Flows, and integrations.

From memory: system validation rules → before triggers → custom validation → save (no commit) → after triggers → assignment rules → auto-response → workflow (and here's the trap: a workflow field update re-fires triggers) → record-triggered processes/flows → escalation → roll-up summaries on parents → sharing → commit → post-commit (email, async). Knowing this in practice is what prevents infinite recursion and 'ghost' results in production — which is why every trigger I write has recursion control from day one.

75% coverage is the deploy minimum, not quality. My tests use a TestDataFactory and @testSetup (never SeeAllData), run bulk scenarios (200 records, not 1), assert with clear messages, use Test.startTest/stopTest to reset limits and fire async, mock callouts with HttpCalloutMock, and cover the negative and permission paths (System.runAs). A test that wouldn't fail if the rule broke isn't a test — it's decoration.

Least privilege, always. Restrictive OWD as the baseline, role hierarchy for vertical visibility, sharing rules for well-defined exceptions. Object and field access through permission sets (and permission set groups) instead of bloated profiles — profiles stay lean, mostly login and defaults. That keeps access auditable and reversible: when someone changes roles, you swap the set instead of hunting checkboxes in a giant profile.

Declarative first: if an admin can maintain the logic tomorrow without me, it's born as a Flow — governed by one record-triggered flow per object/event and reusable subflows. Apex comes in for complex bulk logic, fine-grained transaction and error control, elaborate callouts, or rules that deserve real unit tests. What I won't accept is the same rule living in both — that's a scheduled bug.

Salesforce DX with multiple orgs (DEV → QA → UAT → PROD) and GitHub Actions. JWT OAuth login (no passwords), manifest-driven deploys derived from the branch, quality gates that block leftover debug statements, dry-runs before the real deploy, and versioned destructive changes. Deploys become auditable, boring operations — the way they should be.

Named Credentials keep secrets out of the code, HTTP callouts are wrapped in a reusable service, and endpoints are configured via Custom Metadata instead of being hardcoded. Synchronization is idempotent with control fields, retry/error handling, and mocked callouts in tests. When volume demands it, the bridge goes asynchronous.

A tax engine with effective-dated rules, pre-submission validation in the UI itself (tax IDs, NCM, CFOP), and golden tests that re-run known calculations on every rate change. Issuance goes through a gateway (Focus NFe) with the A1 certificate protected in a secrets vault.

Row-Level Security in the database as the first line — one tenant never sees another's data, not even through an application bug. On top of that, granular RBAC, per-request scoping, and field-level privacy when data is sensitive (private by field, not by record). Secrets in a vault, 2FA, and an audit trail.

Next.js (App Router) gives me SSR, Server Components, and Server Actions to shrink the API surface and latency. For larger domains, a dedicated backend in NestJS or Fastify with Prisma/PostgreSQL. TypeScript end to end, with a shared domain package across web, API, and mobile so types and rules are never duplicated.

A dual-model strategy (a strong model for reasoning, a fast/cheap one for parsing), tool-use with well-defined read-only tools, and always with fallbacks and limits. The AI suggests; critical actions require confirmation. I treat cost, latency, and privacy as requirements, not afterthoughts.

Ingestion through Data Streams → data lands as Data Lake Objects (DLOs) and is mapped to the canonical model in Data Model Objects (DMOs). On top of that I run Identity Resolution with match rules (deterministic by email/phone, rule-based reconciliation) to produce the Unified Individual. Then Calculated Insights for per-profile metrics, segmentation, and Activation to the channels. Where it usually breaks: harmonization across sources, key selection, and each stream's refresh/latency limits.

Native reports and dashboards: operational views over data that already lives in the CRM — always start here; it's what teams adopt fastest. CRM Analytics: historical and advanced analysis, multiple structured sources, prediction with Einstein Discovery. Data Cloud: when the problem is unifying identity at scale, ingesting behavioral/streaming data, and activating segments in near real time. Mature projects combine all three — the classic mistake is buying Data Cloud to solve a reporting problem.

CRM Analytics runs on datasets, not Salesforce objects — so SOQL doesn't apply there; the language is SAQL (with SOQL only at extraction). Data arrives through Dataflows (legacy) or Data Prep Recipes (the modern approach: joins, transforms, even ML nodes). Security comes from security predicates and sharing inheritance. For embedded prediction, Einstein Discovery models are consumable in dashboards and through Apex.

Health Cloud extends the core with clinical objects (Person Account as the patient, Care Plans, clinical/health objects) and FHIR/HL7 mapping for healthcare interoperability. In development, compliance weighs the most: PHI and explicit consent, Shield Platform Encryption for sensitive data, and strict sharing rules (HIPAA/LGPD). Care-management journeys pair naturally with OmniStudio.