Salesforce Architecture Best Practices: The 2026 Decision Rules

Nine hundred custom fields. Three thousand custom objects. Six megabytes of Apex. Two thousand active flows. One hundred SOQL queries per synchronous transaction.

Those are ceilings Salesforce publishes, and no edition upgrade removes them. Every architecture decision an org makes is a withdrawal against that budget. Best practice, stripped of abstraction, is the set of rules governing how the budget gets spent and how much of it survives to year five.

Most guidance on this topic recycles advice that predates the current framework. The pages ranking today for this term were written in 2024 and early 2025, before Christophe Coenraets announced the relaunch of the Salesforce Architecture Program on 12 October 2025, and before Salesforce published a quantified matrix that settles the clicks-versus-code argument with thresholds instead of opinions. This page uses the current material.

The published limits define the architecture budget

Architecture arguments end faster when the ceiling is on the table. The structural figures below come from Salesforce’s Enterprise Edition allocations and its Unlimited Edition equivalent; the transaction figures come from Execution Governors and Limits in the Apex Developer Guide. All read on 8 September 2026 against Winter ’27.

Four details inside that table cause more damage than the headline numbers.

Relationships consume the field budget. Salesforce states that each relationship is included in the maximum custom fields allowed. An org that models everything through lookups is spending its 500 or 800 field allocation on joins. The 900-field ceiling carries further restrictions Salesforce lists separately for activities, long text area fields, relationship fields and roll-up summary fields, so treat 900 as an outer edge rather than a working target.

The Apex ceiling has carve-outs. The 6 MB figure excludes code in first and second generation managed packages and anything in a class annotated @isTest, and scratch orgs get 10 MB. An org close to the limit should confirm what is actually being counted before planning a refactor around it.

Compound fields multiply. A geolocation field counts as three custom fields. A custom address field counts as nine. Twenty address fields consume 180 of the allocation while appearing in a field list as twenty.

Deleted objects keep charging you. Salesforce’s guidance is explicit that soft-deleted custom objects and their data still count against the limit, and recommends hard deleting objects that are no longer needed. Teams that clear space by deleting objects and then find the limit unchanged have met this rule. The sequencing belongs in a planned Salesforce org cleanup rather than in a panic before a release.

Automation density selects the tool, replacing the clicks-versus-code argument

This is the material almost nobody has written about, and it is the single most useful change in Salesforce architecture guidance in years.

Salesforce’s Architect’s Guide to Record-Triggered Automation no longer answers “Flow or Apex” with preference. It answers with measurement. The guide instructs architects to choose the tool based on automation density on a given object, assessed across three dimensions: how many automations exist, what record volume they run against, and how far downstream effects spread.

Four rules travel with that matrix, and each converts a familiar debate into a checkable standard.

One entry point per object. The guide instructs teams to commit to a single primary mechanism and warns that partitioning automation across both Flow and Apex triggers on one object leads to poor maintainability and fragmented governance.

Mega-flows are an anti-pattern, but not for the reason usually given. Salesforce states outright that consolidating all of an object’s automation into a single massive mega-flow is an anti-pattern. It then removes the usual justification, saying that consolidating into one flow versus splitting into multiple well-conditioned flows does not have a major impact on performance. The real gains come from before-save flows for same-record field updates and from precise entry conditions. So the case against mega-flows is maintainability, and anyone defending one on performance grounds is arguing against the vendor’s published position.

Scheduling from a trigger is named as an anti-pattern. Calling System.schedule or Database.executeBatch directly from trigger context is called out by name, on the grounds that it rapidly consumes the asynchronous Apex allocation.

The hybrid pattern has one disqualifying limitation. Invocable Apex has no before-save support, which the guide calls the most critical limitation. Invocable actions run only after save, so the hybrid pattern cannot handle same-record field updates. That work stays in a before-save flow or a before-context trigger.

Two concrete numbers from the same guide are worth carrying into design reviews. A bulk load of 20,000 records fires a trigger in chunks of 200, producing 100 separate trigger invocations, so a single data load can consume a large share of the daily asynchronous allocation. And the queueable limit differs sharply by context: up to 50 jobs can be enqueued from a synchronous UI-triggered transaction, but only one from inside a Batch Apex execute method. The guide calls failing to account for that difference a common and critical failure point.

The practical consequence is that “we use Flow because we are a clicks-not-code shop” stops being an architecture position. It becomes a claim about density an architect can count. If an object carries 34 automations, the platform vendor’s own guidance names a metadata-driven Apex framework as the standard, regardless of team preference.

For mature orgs already running both tools on one object, the guide publishes a refactoring ladder rather than demanding a rewrite. At low density, refactor Apex triggers into record-triggered flows and set execution order. At medium density, break mega-flows into a sequenced subset and introduce Apex only where necessary. At high density, favor Apex triggers. One requirement forces Apex regardless of density: Record-Triggered Flow does not support the after-undelete context, so automation that must run when a record is restored from the recycle bin has no declarative option.

Teams still carrying legacy automation on those objects should sequence the Workflow Rules and Process Builder migration to Flow before measuring density, because retired tools distort the count.

One caution on the guide itself. Its worked example still cites the asynchronous heap limit as 12 MB, which Winter ’27 supersedes. Salesforce updates Well-Architected documents twice a year, so decision guides and release notes drift apart between cycles. Check limits against the release notes rather than against guidance prose.

Well-Architected names anti-patterns rather than describing principles

Salesforce reorganized its architecture guidance around a Patterns Explorer and an Anti-Patterns Explorer, structured as paired statements of what good looks like and what to avoid. The three pillars remain Trusted, Easy and Adaptable, feeding eight mid-level groupings and 22 leaf dimensions. The distribution is uneven rather than symmetric: Trusted carries 9 dimensions, Easy 7, Adaptable 6.

Naming matters here because a paired statement is auditable and a principle is not. Each entry carries a product area, a location to inspect, and a description of what good looks like. Under maintainability, Salesforce publishes these verbatim:

• No objects have names or functionality that duplicates standard objects
• Standard objects are not used for purposes that are far outside their intended scope
• No code attempts to override or circumvent the platform order of execution
• There is a clear guiding principle to keep solutions from unnecessary customization
• Decision records show calculation for near-term and long-term costs when choosing to build or buy
• KPIs for pre-remediation and post-remediation technical debt are clearly documented
• No unsupported or legacy technology is active

The last item is enumerated rather than left vague, which makes it the fastest audit on the list. Salesforce specifies nine conditions: all users working in Lightning Experience, no or very few uses of @future in Apex with Queueable used instead, all third-party Apex belonging to AppExchange packages, no active Workflow Rules, no active Process Builder processes, Change Data Capture in place of PushTopic Events, Platform Events in place of Generic Events, no API versions prior to 30.0, and the Cross-Org Adapter for Salesforce Connect in place of legacy org connections.

Nine checkable conditions produce a finding list in an afternoon. That is a different kind of artifact from a principle, and it is the reason this framework is more useful than the guidance it replaced.

Salesforce also publishes the build priority as an ordered ladder rather than a preference: use built-in platform services first, consider AppExchange apps before building a custom solution, and use low-code customizations before writing code.

The standard-versus-custom test fails in two opposite directions

Most advice on this question runs one way, telling teams to prefer standard objects. Salesforce’s paired anti-patterns run both ways, and the second direction is the one that gets missed.

Building a custom object that duplicates a standard object’s name or function is the first failure. Bending a standard object far outside its intended scope is the second. Teams avoiding the first failure frequently commit the second, loading Opportunity or Case with unrelated processes because using a standard object felt like the safe choice.

The test that resolves it: extend the standard object unless doing so would push it far outside its intended purpose, and build a custom object unless doing so would duplicate something standard. Salesforce’s own framing adds the cost side plainly, stating that no customizations are trivial and that over time every change has consequences.

Where those consequences accumulate and how to measure them is covered in Salesforce technical debt, and the decision rights that stop unmanaged customization belong in a Salesforce governance framework.

Data skew degrades performance long before limits are reached

Governor limits are the visible ceiling. Data distribution is the invisible one, and it bites earlier.

Salesforce’s enterprise-scale record access documentation identifies parent-child data skew at a specific threshold, and words it as a risk rather than a certainty: associating 10,000 or more child records with a single parent account is described as a common configuration that can lead to poor performance, affecting large data loads and updates and sometimes even single-record operations.

Large data volume guidance is deliberately looser. Salesforce calls the term imprecise and elastic, and offers a three-way trigger: tens of thousands of users, tens of millions of records, or hundreds of gigabytes of total record storage. Any one of those means the architecture must be designed differently rather than tuned later.

Two design habits follow. Assume every automation will one day run against large data volumes without notice, which is Well-Architected’s own phrasing. And treat the 10,000-child threshold as a data model constraint rather than a performance problem, because by the time it presents as slowness the model is already in production.

Winter ’27 raised the Apex heap ceiling, changing one common workaround

Architecture guidance goes stale when limits move, and one moved this year.

Salesforce’s Winter ’27 release notes state that the Apex heap limit for synchronous transactions increases from 6 MB to 10 MB, and the limit for asynchronous transactions increases from 12 MB to 25 MB. The change applies to all editions running custom or managed Apex and is enabled automatically according to the Winter ’27 release schedule.

One rollout detail matters for test planning. Sandboxes, Developer Edition orgs and scratch orgs can select a setting to enforce the Summer ’26 heap limit temporarily, and that setting exists only in Winter ’27 nonproduction orgs. Salesforce states the higher limits are enforced globally in Spring ’27 regardless of the setting. So a sandbox can behave differently from production for one release, which is exactly the window in which someone concludes a fix works.

The timing is worth noting for anyone who inherited a workaround. In April 2026, an architect posted on Salesforce Stack Exchange asking how to handle ContentVersion files larger than 12 MB in Apex callouts to S3 without hitting the asynchronous heap limit. Four months later Salesforce raised that limit to 25 MB. Chunking logic written to survive a 12 MB ceiling is now carrying complexity the platform no longer requires.

That is the general lesson rather than a one-off. Workarounds built against a limit should be tagged with the limit they exist for, so that a raised ceiling triggers a review instead of leaving permanent scar tissue in the codebase.

Salesforce also extended its elastic limits beta for asynchronous Apex to Batch jobs in Winter ’27. Read the headroom carefully: the extra allowance is the org’s licensed daily asynchronous execution limit or 2 million executions, whichever is less, so most orgs receive well under 2 million. When jobs pass the standard limit the platform throttles in-flight Batch jobs and restricts new ones to a single active job.

Both changes point the same way. The platform is loosening constraints on transaction volume while leaving the structural limits on objects and fields untouched.

Admins report technical debt as the hardest part of the job

Architecture quality has a measured human cost, and the 2026 numbers are worse than the framing usually admits.

Salesforce Ben’s 2026 Admin Survey, based on 1,134 Salesforce professionals across 72 countries, found that 56.3 percent of respondents named technical debt as the most difficult part of their job, the single most-selected answer. Nearly one in three described their org’s technical debt as high (20.7 percent) or very high (10 percent), with a further 46.6 percent calling it moderate.

The support numbers explain why the problem persists. Only 19.5 percent of admins said they consistently receive strong executive support to address technical debt. Only 18.5 percent felt their executives clearly understand the consequences of leaving it unaddressed, while 10.9 percent said executives do not understand the risks at all.

Gearset’s 2026 State of Salesforce DevOps report, based on 522 respondents of whom 48 percent were Gearset users, adds where the failures surface. Eighteen percent of teams primarily find issues in production. Ten percent have no tooling or process for the operate stage, rising to 17 percent for observe, while teams spend up to half their time on the build stage they already feel most confident about. Read that vendor-user skew as a caution on the absolute figures rather than on the direction.

Both datasets say the same thing in different languages. Architecture standards fail at the review and operate end, not at the design end, and they fail because nobody senior is funded to enforce them.

Practitioners retire the automations that cost more than they saved

Forum evidence from 2026 tracks the survey data closely, and one thread states the problem better than the surveys do.

On 14 May 2026 an r/salesforce post asked whether Salesforce technical debt is inevitable. It drew 73 upvotes and 68 comments. The author, with roughly 15 years managing Salesforce instances, described every org following an identical arc: a clean year one with best practices and documentation, a few customizations in year two, and a Frankenstein monster by year three. The top-voted reply is fatalistic, holding that Salesforce is itself basically tech debt and that documentation is the only available defense.

Set that beside the survey data and the two agree. Admins name technical debt as the hardest part of the job, four in five report inconsistent executive support, and the practitioner consensus is that decay is structural rather than a personal failure.

One structural observation about where this conversation now happens. A search of Salesforce Stack Exchange for architecture questions between February and September 2026 returns 23 results, none scoring above 3 votes, none carrying more than 2 answers, and many carrying none. Every one is a narrow implementation problem: iframe embedding, SCIM provisioning, CSV import mapping, heap limits. The strategy conversation has left the technical archive for Reddit, which means the pattern evidence architects most need sits in threads that are harder to search and easier to lose.

GetGenerative.ai agents apply standards at review rather than at design

The evidence above converges on a specific bottleneck, so it is worth naming where our own model sits against it.

Architecture standards do not fail because teams cannot write them. They fail because enforcing them is unfunded manual work that competes with delivery, which is exactly what 19.5 percent executive support and 18 percent production-discovered defects describe.

GetGenerative.ai runs Salesforce delivery through pods where a Forward Deployed Engineer leads and six purpose-built agents (Discovery, Metadata, Design, Build, Test and Support) carry production work. The pod’s second stage is analyze, described on the site as understanding the org and its metadata, and it runs before any design work begins.

That sequencing matters for the checks in this article. Counting automations per object to establish density, testing an org against the nine legacy technologies Salesforce enumerates, and finding objects whose names duplicate standard objects are all enumeration problems. Enumeration is the part of architecture review that scales with machine reading and does not scale with human attention.

What agents do not do is decide whether a standard object is being used far outside its intended scope. That is a judgment about business purpose, and it stays with the engineer. GetGenerative.ai sets a minimum of 12 years Salesforce delivery experience for its FDEs for that reason, and the split is the same one running through every section above: the platform publishes countable rules and uncountable ones, and only the countable half can be delegated.

An honest limitation belongs here too. Automated metadata analysis identifies where standards are violated. It does not establish whether the violation was a deliberate trade-off recorded by a previous architect or an accident, and treating every finding as a defect produces remediation backlogs nobody works. The output needs a human pass before it becomes a plan. Teams wanting that pass run as a defined exercise should start with a Salesforce org assessment; teams wanting it run continuously should look at AI-powered managed services.

Adjacent decisions this page does not cover

Three architecture questions sit outside this scope and have their own treatment. Whether to run one org or several is set out in single org or multi-org strategy. Environment design and refresh cadence belong in Salesforce sandbox strategy. What changes for the architect role when agents draft designs is covered in the AI-ready Salesforce architect.

The limits table, for reference

What this comes down to

Salesforce publishes a finite architecture budget and, since October 2025, a quantified way to spend part of it. Automation density thresholds replace the clicks-versus-code debate with counting. Named anti-patterns replace principles with an audit list. The limits that moved in Winter ’27 are the heap ceilings, not the structural ones. The constraint on good architecture is review capacity, not knowledge.

Architecture questions teams ask most

How many automations on one object are too many?

Salesforce’s record-triggered automation guide sets thresholds. Fewer than 15 automations with light downstream impact suits Record-Triggered Flow. Between 15 and 30 calls for Flow with Invocable Apex. Above 30, or with five or more downstream DML operations, the published standard is an Apex trigger metadata framework.

Should I extend a standard object or create a custom one?

Extend the standard object unless that would push it far outside its intended purpose. Create a custom object unless it would duplicate a standard object’s name or function. Salesforce publishes both failures as named anti-patterns, so the test runs in two directions rather than defaulting to standard.

What are the hard limits I cannot buy my way past?

Most object types cap at 900 custom fields and orgs cap at 3,000 custom objects regardless of edition or package source. Apex across the org is capped at 6 MB, though support can raise it. Relationships count against the field allocation, and geolocation and address fields count as three and nine respectively.

Did any Salesforce limits change in 2026?

Yes. Winter ’27 raises the Apex heap limit from 6 MB to 10 MB for synchronous transactions and from 12 MB to 25 MB for asynchronous ones, enabled automatically across editions. The elastic limits beta for asynchronous Apex also extended to Batch jobs, capped at 2 million additional executions.

When does data volume force an architecture change?

Salesforce calls large data volume elastic rather than fixed, triggering at tens of thousands of users, tens of millions of records, or hundreds of gigabytes of storage. The one hard number published is parent-child data skew, where 10,000 or more child records under a single parent degrades loads, updates and single-record operations.