Salesforce Architecture Review Checklist

Most architecture reviews produce a list of findings nobody acts on. The org gets a PDF, the PDF gets filed, and six months later the same problems surface in a production incident. A useful salesforce architecture review checklist doesn’t catalog symptoms. It identifies the structural decisions that will cause failures at the next order of magnitude.

This is the framework I use when assessing an org before a major program, a platform migration, or a post-acquisition integration. It’s organized around failure modes, not feature categories.

Why Most Org Audits Miss the Real Risk

The standard approach is to run a health check tool, export the results, and flag anything in the red zone. That catches obvious problems: API limits, storage thresholds, inactive users with admin profiles. What it doesn’t catch is the architectural debt that only becomes visible under load.

A common pattern in enterprise orgs: the health check shows green across the board, but the data model has 47 custom objects on Account with no clear ownership boundaries. Every new feature gets bolted onto Account because that’s where the data already lives. The org functions fine at current volume. At 3x the record count, or when a second cloud gets added, the query performance collapses and the automation chain starts timing out.

The risk isn’t in the metrics. It’s in the decisions that shaped the architecture.

The Five Domains That Determine Org Structural Health

A complete review covers five domains. Each one has a primary failure mode that shows up predictably when orgs scale or integrate.

1. Data Model Integrity

Start here. The data model is the foundation everything else runs on, and it’s the hardest thing to fix after the fact.

What to assess: object relationships and cardinality, field proliferation on core objects (Account, Contact, Opportunity), the ratio of custom objects to standard objects, and whether the model reflects the actual business domain or the history of individual project decisions.

The failure mode is object overloading. When Account carries fields from Sales, Service, Finance, and Marketing with no clear separation, you get permission complexity, reporting ambiguity, and automation conflicts. The fix at that point requires a data migration, not a configuration change.

Also check for missing external ID fields on objects that participate in integrations. Orgs that rely on Salesforce record IDs as the integration key are one org refresh away from broken data pipelines.

2. Automation Architecture

Flow is the current standard. If the org still has active Process Builder or Workflow Rules handling business logic, that’s not just a technical debt flag, it’s a reliability risk. Both are deprecated. Salesforce has committed to removing them, and the migration path requires deliberate re-architecture, not a one-click conversion.

The more important question is whether the automation is coherent. In practice, the worst orgs don’t have too much automation. They have automation that was built by different teams at different times with no shared design. You end up with three Flows firing on the same object trigger, each written by a different developer, with no documentation of the intended execution order.

Check for: recursive Flow triggers without explicit termination conditions, DML operations inside loops (a governor limit problem waiting to happen), and Flows that duplicate logic already handled in Apex. The last one is particularly common after team turnover. Someone builds a Flow because they don’t know the Apex class exists.

3. Integration Architecture

Map every external system touching the org. Not just the documented integrations. Pull the Connected Apps list, the Named Credentials, the External Services definitions, and cross-reference them against active API usage logs.

In orgs that have been running for five or more years, it’s common to find three or four integrations that nobody can explain. They’re still active, still consuming API calls, and the team that built them left the company. That’s both a security surface and a governor limit drain.

For current integrations, assess the pattern. Point-to-point REST integrations between Salesforce and external systems work until you need to change either side. The architecture that survives at scale uses MuleSoft or an equivalent integration layer as the contract boundary, so Salesforce and the external system can evolve independently. If the org has direct integrations to 12 different systems, that’s 12 potential breaking points with no circuit breaker.

Also check Platform Events usage. Real-time event-driven patterns are the right approach for high-volume async processing. If the org is using synchronous callouts for operations that could be decoupled, that’s a latency and reliability problem.

4. Security and Access Architecture

Profile and permission set architecture is where orgs accumulate the most invisible debt. The pattern that breaks at scale: a handful of profiles with broad access, supplemented by an ever-growing list of permission sets that nobody has audited in two years.

Run a permission analysis on the System Administrator profile. In a surprising number of enterprise orgs, 40-60 users have System Administrator access because it was easier than building a proper permission model. That’s not a security posture. That’s a liability.

Check sharing rules and OWD (Organization-Wide Defaults) against the actual business requirements. Orgs that started with Public Read/Write on core objects and later tried to tighten access face a painful migration. The reverse is easier. Start restrictive, open up as needed.

For orgs using Agentforce or planning to, the security review needs to extend to agent permissions. The Atlas Reasoning Engine operates within the running user’s permission context, but Topics and Actions need explicit scoping. An agent with access to a poorly scoped Action can surface data it shouldn’t. This is an architectural decision, not a configuration checkbox.

5. Release and Deployment Architecture

How the org is deployed tells you as much about its health as what’s in it. An org with no version control, no sandbox strategy, and deployments done directly in production is an org where every change is a production incident waiting to happen.

The minimum viable deployment architecture for an enterprise org: a scratch org or developer sandbox for feature development, a full sandbox for UAT, a staging sandbox that mirrors production for final validation, and a CI/CD pipeline (even a basic one using Salesforce CLI and GitHub Actions) that enforces code review before anything reaches production.

Orgs that have grown without this structure typically have metadata drift between sandboxes and production. The sandbox says one thing. Production says another. Nobody knows which is authoritative. That’s the condition that turns a routine deployment into a four-hour rollback.

What to Do With the Findings

A review without a remediation plan is just documentation. Prioritize findings across two axes: blast radius (how many processes or users does this affect if it fails) and remediation complexity (how hard is it to fix).

High blast radius, low complexity: fix immediately. These are usually security misconfigurations and deprecated automation that can be migrated with focused effort.

High blast radius, high complexity: these become program-level initiatives. Data model restructuring and integration re-architecture fall here. They require dedicated resourcing and a phased approach, not a sprint.

Low blast radius, low complexity: batch these into a technical debt backlog and work through them systematically. Field cleanup, inactive automation, orphaned permission sets.

Low blast radius, high complexity: deprioritize unless there’s a specific trigger (a new integration, a cloud addition) that elevates the risk.

The current decision about which quadrant gets resourced determines whether the org is buildable in 18 months or whether the next major program gets slowed down by the weight of accumulated decisions nobody wants to revisit.

For orgs that have reached the point where the debt is systemic, the Org Health & Recovery Architecture engagement model exists specifically for this: structured assessment, prioritized remediation roadmap, and architectural guardrails to prevent the same patterns from recurring.

Key Takeaways

• A salesforce architecture review checklist organized around failure modes surfaces structural risk that health check tools miss entirely.
• Data model integrity is the highest-leverage review domain. Object overloading on Account and Contact is the most common root cause of performance and automation failures at scale.
• Active Process Builder and Workflow Rules are not just technical debt; they are a reliability risk given Salesforce’s deprecation commitment. Migration requires re-architecture, not conversion.
• Integration point-to-point patterns work until they don’t. Orgs with 10+ direct integrations need an integration layer with a defined contract boundary before adding another cloud.
• Security architecture debt compounds. Broad profile access and unaudited permission sets are the conditions that make Agentforce agent scoping dangerous rather than manageable.
• Remediation prioritization by blast radius and complexity is the only approach that produces an actionable roadmap rather than an overwhelming findings list.