Architectures that hold up

One record-triggered flow per object per timing (one before-save, one after-save) that delegates to named, ordered subflows, giving you deterministic order of execution instead of automations racing each other.

WhenOnce an object carries more than a couple of automations, or the moment you see intermittent save bugs that only reproduce under bulk load. Retrofit it on any object with stacked flows, workflow rules, and process builders.

Pattern
1. 01One before-save flow per object for same-record field writes (fast, no DML cost).
2. 02One after-save flow per object for cross-object writes, callouts, and async work.
3. 03Named subflows called in an explicit sequence, one per business concern (routing, stamping, rollups).
4. 04Entry criteria on every subflow so it runs only when its trigger conditions are met.
5. 05A recursion guard (transaction-scoped flag or a field-change entry check) so a flow does not re-fire on its own write.

BenchmarkAverage save CPU time: stay well under the 10,000 ms synchronous Apex CPU limit, with practitioner headroom below ~5,000 ms. Source: Salesforce Apex Developer Guide, per-transaction governor limits.

A giant undecomposed flow is as unmaintainable as the sprawl it replaced, and before-save runs before the record exists in the database, so misplaced logic either fails silently or forces a redesign.

A per-field ownership map that names exactly one system of record for every shared fact, plus a scheduled job that diffs the systems and surfaces drift, so that when two systems disagree there is a defined winner and a human sees the gap.

WhenAny time the same fact (ARR, opportunity stage, account status) lives in two or more systems: CRM, billing, CPQ, the warehouse, enrichment.

Pattern
1. 01A field-level system-of-record matrix: field, owning system, sync direction, cadence.
2. 02One-way writes wherever possible, so the non-owner can never overwrite the owner.
3. 03A scheduled reconciliation query that compares shared fields across systems.
4. 04A drift exception queue routed to a named owner, not a shared inbox or an unwatched dashboard.
5. 05A published tolerance per field class (for example, financial fields under 1%).

BenchmarkReconciliation drift: under 1% on financial fields (practitioner target). Source: site integration and sync metrics.

A drift report with no owner and no SLA is decoration, and if the named system of record is not where the data is genuinely created, reconciliation fights the real workflow every night.

An inbound write pattern keyed on a stable external ID and executed as an upsert, so replays, retries, and double-fires converge to a single record instead of spawning duplicates.

WhenEvery inbound integration that can retry, batch, or fire twice: marketing automation sync, webhooks, ETL loads, enrichment appends.

Pattern
1. 01An indexed External ID field on the target object as the match key.
2. 02Upsert on that key, never a bare insert on receive.
3. 03A deterministic key derived from the source system's stable id, not a mutable value like email.
4. 04A dead-letter or error queue for records that fail to match or validate, so nothing drops silently.
5. 05An at-least-once delivery assumption baked in from the start (assume the message will arrive twice).

BenchmarkResidual duplicate rate: under 2% on managed keys (practitioner target). Source: site data-quality metrics.

An upsert is only idempotent if the key is stable and unique; a mutable or non-unique key quietly reintroduces the exact duplicates the pattern exists to prevent.

A reference object chain (Opportunity to Quote to QuoteLine to Order and OrderItem to Contract and Asset to Invoice, that last step in Revenue Cloud or a billing system) with price and discount governed at the quote line, so the number that closes is the number that bills.

WhenWhenever you have configured products, discount approvals, ramps, or renewals, and finance needs quote-to-invoice to tie out.

Pattern
1. 01A product catalog and price book as the single price source, not free-text amounts.
2. 02Quote lines carrying list, discount, and net, with approval gates on discount thresholds.
3. 03An ordered handoff that copies the negotiated price forward into Order and Contract, rather than re-deriving it.
4. 04Renewal and amendment opportunities generated from the Contract or Asset, not hand-built each cycle.
5. 05A quote-to-invoice reconciliation check as a closing control.

BenchmarkQuote-to-invoice tie-out: near 100% agreement on net price. This is an internal control target, not a published benchmark.

Quote-to-cash only ties out if downstream objects inherit the negotiated numbers; any stage that recomputes price breaks the audit trail between what sold and what bills.

A deliberate object and relationship design (which standard objects, minimal custom objects, record types to fork process, one field with one meaning) locked before any field gets created, so the schema reflects the business instead of accreting one request at a time.

WhenA new org build, a major new motion (adding CS, partners, usage billing), or right before a field-adding spree that would otherwise bloat every layout.

Pattern
1. 01An entity-relationship model on the standard objects first (Account, Contact, Opportunity; Lead only where a true pre-qualification stage exists).
2. 02Custom objects only for entities with their own lifecycle, never for what is really an attribute.
3. 03Record types to fork process, not to duplicate near-identical fields.
4. 04One field, one definition, one owner, reused across teams instead of cloned per team.
5. 05A field-request intake gate that checks for an existing field before creating a new one.

BenchmarkOrphaned field rate: under ~15% (practitioner target); mature orgs commonly run 20 to 40% unused. Note the hard ceiling: Salesforce caps custom fields per object by edition (Enterprise 500, Unlimited/Performance 800). Source: site technical-debt metrics; Salesforce edition allocations (verify the exact cap against your org).

An elegant model nobody can enter data into fails as hard as sprawl; the model has to match how reps actually work, not just how the data theoretically decomposes.

A source-controlled release path (git as the source of truth, sandbox build, validated deploy, prod promotion) that makes every change to the revenue system reviewable, testable, and reversible.

WhenAs soon as more than one person can change the org, or the first time a config change broke something downstream that nobody caught until a report looked wrong.

Pattern
1. 01Metadata in git as the source of truth (source-driven development, not click-and-pray).
2. 02A build-and-test sandbox that mirrors production, including data volume.
3. 03Validate-only deploys with tests run before anything promotes.
4. 04A promotion step to prod via CI or change sets, with no live editing in production.
5. 05A rollback plan and a change log tying each deploy to a ticket.

BenchmarkChange failure rate: under 15% (elite band 0 to 15%). Source: DORA / Google Cloud State of DevOps; aligns with the site technical-debt metric.

A pipeline protects you only if it is the sole path to prod; every out-of-band production edit desyncs the repo and reintroduces the risk the pipeline was built to remove.

A phased data migration (map, load to sandbox, reconcile, cutover) keyed on external IDs, where a row-and-sum reconciliation must pass before cutover, so you never flip to the new system on unverified data.

WhenA CRM replatform (HubSpot to Salesforce), a post-acquisition merge, or any bulk load where the old system numbers are the accepted truth.

Pattern
1. 01A field-and-object mapping document with owner sign-off before a single row moves.
2. 02An external-ID column carrying the source record id into every target record, for idempotent reloads and audit.
3. 03A load into a full sandbox first, in dependency order (accounts before contacts before opportunities).
4. 04A reconciliation gate comparing counts and key sums (record counts, open pipeline, ARR) old versus new.
5. 05A dated cutover with the old system frozen read-only.

BenchmarkReconciliation gate: record counts and ARR / open-pipeline sums must match the old system within a published tolerance before cutover. Internal control gate, no external benchmark.

Matching counts proves rows arrived, not that they are correct; the sums (ARR, open pipeline) are what leadership checks on day one, and lookups loaded before their parents orphan on arrival.

A layered access model (locked-down org-wide defaults, lean profiles for baseline, permission sets and permission set groups for grants, role hierarchy and sharing rules for record visibility) that gives each persona the minimum it needs and keeps access auditable.

WhenAny multi-team org, and mandatory once you handle regulated data, external community users, or have more than one admin.

Pattern
1. 01Restrictive org-wide defaults (private on the sensitive objects) as the floor.
2. 02Lean profiles for baseline settings, with permissions granted through permission sets and permission set groups per persona.
3. 03Role hierarchy plus sharing rules for record-level visibility, not field-level workarounds.
4. 04Least privilege on Modify All / View All and on field-level security for sensitive fields.
5. 05A periodic access review that diffs granted access against needed access.

Broad all-data permissions are the access-review nightmare and the compliance finding; they solve today ticket by creating a standing exposure nobody remembers to revoke.