An independent, read-only assessment of how your Salesforce org is actually built. Senior engineers examine the data model, automation, integrations, security, scalability and DevOps practice — and hand you a documented current state, a ranked risk register and a roadmap for fixing what matters first.
A Salesforce architecture review is a structured, independent assessment of how a Salesforce org is designed and built. It examines six areas: the data model (objects, relationships, volumes and sharing), automation (Flows, Apex triggers and their interaction), integrations (APIs, events, middleware and error handling), security (profiles, permission sets, sharing rules and external access), scalability (governor limits, query performance and data growth) and DevOps practice (version control, environments, testing and release management). The output is a documented picture of the current architecture, a register of risks ranked by severity and likelihood, and a sequenced set of recommendations. Unlike a feature audit, an architecture review evaluates structural decisions — the ones that determine whether an org can absorb new requirements, higher volumes and additional teams without breaking. Reviews are typically commissioned before major platform investments, after an org changes hands, or when delivery has become slow and fragile.
Salesforce orgs are rarely designed once; they accumulate. Requirements land sprint by sprint, admins and partners rotate, and every individual change looks reasonable at the time it is made. A few years in, the org behaves in ways no single person can fully explain. That is normal — but structural problems compound quietly. Rework gets more expensive, releases slow down, and incidents start appearing in areas nobody touched. An architecture review replaces anecdote — “the org is slow”, “releases keep breaking” — with evidence, so decisions about the platform are made on facts rather than folklore.
The strongest signals that it is time:
One honest counter-signal: if the org is young, the team is small and the pain is a feature backlog rather than fragility, a full review is premature. A lighter Salesforce health check will surface the obvious risks at a fraction of the effort — and it can be upgraded to a full review if the results warrant it.
Six domains, always. Skipping one is how orgs end up with a beautiful data model behind an integration layer held together with unmonitored retries.
Objects and relationships are mapped against the entities the business actually manages. The review looks for overloaded standard objects, duplicated concepts, record-type sprawl and structured data hiding in free-text fields — then examines volumes: data skew, ownership skew, lookup skew, indexing and query selectivity on the largest tables. The data model is the most expensive layer to change later, so it gets the deepest scrutiny.
A full inventory of Flows, Apex triggers and any remaining Workflow Rules and Process Builders, mapped per object. The review examines order of execution, recursion control, bulkification, error handling and observability — and whether logic sits at the right layer at all. Configuration, Flow and Apex each have a place; our decision framework shows where that boundary belongs, and the review flags where it has been crossed.
Every connection in and out of the org, traced end to end: pattern choice (synchronous REST, Platform Events, Change Data Capture, middleware), authentication and credential storage, idempotency, retry behaviour, failure handling and API limit consumption. Integrations are where orgs fail loudest in production — and where the gap between the diagram and reality is usually widest.
The sharing model is tested against what the business needs today, not what it needed at go-live. Profiles versus permission sets, over-broad administrative rights, integration user privileges, external access through Experience Cloud sites and connected apps, and field-level security on sensitive data. Where the findings warrant it, we recommend extending into a dedicated security review.
How the org behaves as volumes grow: governor-limit headroom in the critical transactions, synchronous versus asynchronous processing, batch and queueable design, report and list-view performance against the largest objects, storage trajectory and archiving strategy. The goal is to find the ceilings before the business hits them — limits are documented, but headroom rarely is.
How change reaches production: version control coverage, sandbox and environment strategy, test depth — assertions, not just a coverage percentage — deployment tooling, release cadence and the ability to roll back. A weak delivery pipeline turns every other risk in the register into a recurring one, because fixes ship through the same fragile path that caused them.
Clouderia is a boutique Salesforce engineering consultancy — 46 certified experts across Provo, Utah and Prague, building on the platform since 2010 for telco, financial services, insurance, nonprofit, automotive and SaaS companies. Architecture reviews sit inside our advanced development services and are run by senior engineers who design and build orgs for a living, not by a junior team working through a checklist. The same discipline we apply to our own products, TransactionHub and CollectiPro — versioned, tested, documented — is the standard the review measures against.
A short call to agree which orgs, integrations and business processes matter most, what is worrying you, and what the review should optimise for. You get a fixed price and a timeline before anything starts.
Read-only access is provisioned. Metadata, code and configuration are extracted and analysed, limit and performance data is collected, and the people who know the org's history are interviewed. Nothing is changed in the org.
The critical business processes are traced end to end across all six domains. Every finding is tied to concrete evidence in the org and rated by severity and likelihood — no generic best-practice filler, no findings we cannot defend.
A written report, risk register and remediation roadmap, presented in a working session where your team can challenge, reprioritise and plan. Anything urgent — a security exposure, an approaching limit — is escalated earlier, as soon as it is found.
If the roadmap surfaces more remediation than your team can absorb, the follow-on options range from targeted fixes to a structured technical debt rescue. But the review is priced and delivered as a standalone engagement, and many clients execute the roadmap entirely on their own.
Some findings recur across orgs regardless of industry. These are the patterns we look for first, because they predict future incidents with depressing reliability.
The Account object doing triple duty as customer, partner and household. Record types standing in for proper entity modelling. A child object with millions of rows under a handful of parents — data skew that makes sharing recalculation and queries degrade unpredictably. Critical business data held in free-text fields where it can be neither validated nor reported on.
Multiple unmanaged triggers on the same object with no framework and no ordering contract. Flow, Apex and legacy Workflow Rules all firing on the same record, so the order of execution depends on tribal knowledge. Recursion suppressed with static booleans instead of being designed out. Hardcoded record IDs that silently break in every sandbox.
Callouts made directly from triggers. Integrations with no idempotency, so every retry creates a duplicate. Secrets stored in custom settings instead of Named Credentials. Polling loops quietly consuming a large share of the daily API allowance. No monitoring — so integration failures are discovered by end users, weeks later.
Integration users running with full administrator profiles. “Modify All Data” granted to work around a sharing problem nobody diagnosed. A sharing model opened up because private sharing performed badly under skew. Experience Cloud guest access wider than anyone remembers approving.
SOQL queries inside loops that pass tests on ten records and fail in production on ten thousand. Non-selective queries against multi-million-row objects. Synchronous processing already near CPU limits, with no headroom for the growth the business is forecasting. Batch chains with no error handling, silently dropping records.
Production as the only source of truth, with no version control. Tests written to satisfy the coverage requirement, with no meaningful assertions. Deployments assembled by hand from change sets. No rollback plan beyond “fix forward and hope”. Our Salesforce code review guide covers what good looks like at the code level; the architecture review checks whether the pipeline around the code can sustain it.
Most reviews run two to four weeks from access to final readout, depending on the size of the org, the number of integrations and how much documentation already exists. A single-cloud org with a handful of integrations sits at the short end; a multi-cloud estate with managed packages, middleware and several delivery teams takes longer. Scope and timeline are agreed before the engagement starts.
Cost is driven by scope: how many clouds and managed packages the org runs, the volume of custom code and automation, how many integrations need to be traced end to end, and whether the review should extend into performance analysis or DevOps tooling. Clouderia quotes a fixed price after a short scoping call, so the engagement has a known cost before it begins.
Read-only access to a full sandbox or the production org, plus the source repository if one exists. We also ask for a few hours of interview time with an admin or developer who knows the org's history, and access to integration documentation or middleware consoles where relevant. No changes are made during a review, and access can be revoked the day the readout is delivered.
A health check is a fast, broad scan of org hygiene: limit consumption, unused metadata, obvious risks. An architecture review goes deeper — it evaluates the structural decisions behind the org, traces critical processes and integrations end to end, and produces a prioritised remediation roadmap. Many teams start with a health check and commission a review when the scan surfaces structural questions it cannot answer.
No. The review is read-only and runs alongside normal delivery. It needs a few hours of interviews with the people who know the org, spread across the engagement, and nothing else from the team's calendar. Anything urgent — a security exposure, an approaching platform limit — is escalated as soon as it is found rather than held for the final readout.
Yes. Inherited orgs are one of the most common reasons reviews are commissioned. The report documents what exists without assigning blame: each finding describes the risk, its impact and the order in which to address it. Remediation can then be done by the incumbent partner, an internal team, or by Clouderia — the review stands on its own either way.
Everything produced during the review belongs to you: the architecture documentation, the risk register and the roadmap. Some clients execute the roadmap internally; others ask Clouderia to remediate the highest-severity findings or to take on a full technical debt rescue. There is no obligation in either direction — the review is scoped and priced as a standalone engagement.
Scope a fixed-price architecture review with a senior Salesforce engineer.