Key takeaways
- A review interprets your org against known anti-patterns and hands you a risk-ranked, sequenced fix plan — not a metrics dump like Optimizer.
- Six areas: data model, sharing and visibility, integration, automation, technical debt, release process.
- Commission one before a major build, after a project goes sideways, or before an Agentforce/AI rollout — AI does not forgive the debt human users work around.
- A good deliverable is short: findings register, severity-vs-effort risk ranking, sequenced remediation plan.
A Salesforce architecture review is an independent examination of how your org is built: its data model, sharing model, integrations, automation, technical debt, and release process. It produces a risk-ranked findings report and a sequenced fix plan, so you know what to repair before it becomes expensive to unwind.
The search results for this topic are full of career advice (“how much does a Salesforce architect make?”) and framework documentation. Neither answers the question a buyer actually has: what does a review look at, and when is the right moment to commission one. This guide covers both, from an architect’s seat.
What is a Salesforce architecture review?
A Salesforce architecture review is a structured assessment of your org against known patterns and anti-patterns. An architect inspects metadata, configuration, and code, then reports where the current design creates risk, cost, or a ceiling on future work. The output is findings ranked by severity, not a certificate that everything is fine.
It differs from a Salesforce Optimizer run or a Well-Architected self-check. Those tools surface metrics. A review interprets them. A sharing rule sitting near its limit is a metric; whether that limit will block your next business unit rollout is an architectural judgment. The value is in the interpretation and the sequencing, which is why an experienced reviewer matters more than the tool they run.
At Tucario every engagement is architect-led, and a review is often where we start. Reading an org tells us more in two weeks than a workshop tells us in two months.
What a Salesforce architecture review covers, area by area
A thorough review walks six areas. Each one maps to a class of failure we see repeatedly in enterprise orgs. Use this as a scope checklist when you commission a review, or as a self-audit before you decide you need one.
| Review area | What it examines | Common red flags |
|---|---|---|
| Data model | Object relationships, field sprawl, record types, ownership | Duplicate fields for the same concept, junction objects misused, records owned by a deactivated user |
| Sharing and visibility | Org-wide defaults, role hierarchy, sharing rules, team access, Apex sharing | Public Read/Write used as a workaround, sharing rules near the per-object cap, ownership skew |
| Integration | Inbound and outbound patterns, API consumption, error handling, middleware | Point-to-point sprawl, no retry or idempotency, hardcoded endpoints and IDs |
| Automation | Flows, Apex triggers, order of execution, bulkification | Multiple triggers on one object, unbulkified loops, abandoned flows left active |
| Technical debt | Unused metadata, hardcoded IDs, test coverage quality, deprecated API versions | Coverage sitting at exactly 75%, dead code, one-off fields from old projects |
| Release process | Source control, sandbox strategy, deployment method, environment parity | Changes made directly in production, no single source of truth, manual deployments |
The data model is where most reviews start, because everything above it inherits its problems. Field sprawl is the quiet one: an org accumulates three fields that mean “region” because three teams each added their own. Reports disagree, automation forks, and nobody trusts the numbers.
Sharing and visibility is where reviews find the scariest issues, because they are invisible until an audit or a breach exposes them. Org-wide defaults set to Public Read/Write to “make it work” hand every user every record. We check whether the sharing model was designed or accreted.
Data quality sits underneath the data model, so a review looks at it too. Tucario’s Salesforce-native app, DQS, runs batch scans that detect and report data quality issues across your objects. It flags them for the architect to act on; it does not auto-fix or merge records. A review uses that visibility to separate a design problem from a data-hygiene problem, because the fixes are different.
Automation and integration together decide whether your org survives volume. We trace the order of execution on your busiest objects and look for the triggers, flows, and processes that fire in an order nobody planned. On integration we check whether a failed callout retries, alerts, or silently drops data.
When should you get one?
Get an architecture review at one of three moments: before you commit budget to a major build, after an implementation has gone sideways and you need an independent read, or before an Agentforce or AI rollout that will expose every weakness in your data and sharing model. Each triggers for a different reason.
Before a major build is the cheapest time. A review here tells you whether your foundation can carry what you are about to put on it. Spending two weeks confirming the data model holds is far cheaper than discovering mid-project that the sharing model cannot support the new business unit. This is the moment most teams skip and most regret.
After an implementation has gone sideways, an independent review does something the incumbent partner cannot: tell you the truth without defending prior decisions. If a project is late, over budget, or quietly abandoned by users, a review separates what to salvage from what to rebuild. Before an Agentforce or AI rollout, a review is close to mandatory. An agent grounded on a messy data model and permissive sharing will surface the wrong records to the wrong people, confidently. AI does not forgive the technical debt that human users learned to work around. Reviewing before you deploy agents is far less painful than debugging their answers afterwards.
What a good review deliverable looks like
A good deliverable is short, ranked, and sequenced. It lists findings by severity, explains the risk each one carries in plain business terms, and proposes fixes ordered by risk against effort. A 100-page PDF that documents every field is an inventory, not a review, and it ends up unread on a shared drive.
The format we hand over has three parts. First, a findings register: each issue, its severity, and the concrete consequence if left alone. Second, a risk ranking that plots severity against the effort to fix, so leadership can see the quick wins and the structural projects at a glance. Third, a sequenced remediation plan, because fixing debt in the wrong order can make the next fix harder.
Sequencing is the part tools cannot produce. Unpicking a sharing model before you fix the ownership skew underneath it wastes the effort. A reviewer who has done the remediation, not only the diagnosis, knows which thread to pull first.
In-house review vs independent review: the honest tradeoff
If you have a strong internal architect with time to spare and no stake in the decisions being reviewed, do it in-house. Nobody knows your business context better than your own team, and a self-review costs nothing but calendar. When your architect built the org recently and the questions are tactical, an external review adds little.
The case for an independent review is specific. You want it when the people who built the org cannot objectively assess it, when the internal team is too close to see the accreted workarounds as problems, or when a decision (rebuild, replatform, keep going) needs a read that carries no internal politics. Independence is the product as much as the technical depth.
There is a middle ground worth naming: a fractional architect who reviews first and then stays to steer the fixes. We describe that model separately in our fractional Salesforce architect guide. It suits a team that has the delivery hands but not the design authority.
A word on credentials, because they matter here. Tucario’s reviews are led by a Salesforce Certified Technical Architect, a credential held by fewer than 500 people worldwide. That background is not a badge; it is the pattern exposure that lets a reviewer tell a genuine risk from a cosmetic one across 50+ enterprise engagements and 7 industry verticals.
Where to go from here
If you are weighing a major build, recovering a stalled one, or preparing for Agentforce, an independent read of your org de-risks the decision before you spend on it. Tucario runs architect-led reviews that end in a ranked, sequenced plan you can act on, not a document you file away. See the Architecture Review service for scope and engagement shape.
If you would rather self-assess first, run the six-area checklist above against your org this week. It will tell you whether the problems you feel are design, data, or process, and that alone changes what you fix next.
Frequently asked questions
What is the difference between a Salesforce architecture review and a health check?
A health check, such as Salesforce Optimizer, reports metrics: limits, unused fields, coverage numbers. An architecture review interprets those metrics against your business context and future plans, then hands you a ranked, sequenced fix plan. The health check tells you what; the review tells you what it means and what to do.
How long does a Salesforce architecture review take?
Timelines are scope-dependent and indicative, but a focused review of a single-cloud org commonly runs two to three weeks: reading metadata and code, interviewing key admins, and producing the findings deliverable. Larger multi-cloud orgs with heavy integration take longer. The output arrives as a ranked report, not an open-ended engagement.
Do I need an architecture review before implementing Agentforce?
Yes, in almost every case. Agentforce grounds its answers on your data model and honours your sharing model. Both flaws and permissive defaults become visible fast once an agent starts surfacing records to users. Reviewing and fixing the foundation before deployment is far cheaper than debugging an agent’s wrong answers in production.
Can I do a Salesforce architecture review in-house?
You can, if you have a strong internal architect with spare time and no stake in the decisions under review. In-house works well for tactical questions on a recently built org. Commission an independent review when objectivity matters: a rebuild-or-continue decision, a stalled project, or an org too familiar to its builders to see its own workarounds.
What does a Salesforce architecture review deliverable include?
Three things: a findings register with each issue’s severity and business consequence, a risk ranking that plots severity against effort to fix, and a sequenced remediation plan. It is deliberately short and actionable. A hundred-page metadata dump is an inventory, not a review, and it rarely changes what a team does next.
Michał Bajdek
Co-Founder, Tucario
Co-founder of Tucario, a Salesforce consulting and product engineering firm. Works across enterprise Salesforce delivery — architecture, integrations and AppExchange products — and writes about what holds up in production.