Technical Leadership & Architecture Governance

A Salesforce architecture review should create decisions—not delay delivery

JSBC Labs29 October 20268 min read

A meeting is not a control

A delivery team spends three weeks designing a new integration, then presents forty slides to an architecture board two days before build starts. Reviewers raise identity, volume and recovery questions that should have shaped the design from day one. The team either slips the release or records vague actions and proceeds. The organisation has an approval meeting, but it does not have effective architecture governance.

Salesforce Well-Architected describes its framework as a lens for design reviews, trade-off conversations and ongoing governance rather than a prescription for one right answer. Its security guidance says review at proposal stage, before significant build investment, because review after development is too late to influence fundamental choices. The JSBC Labs position is that architecture review must create a timely, durable decision. Attendance, slides and signatures are only supporting mechanics.

Review risk, not every ticket

Sending every Flow, field and permission change to the same board turns architects into a queue. Define review triggers instead: new system boundaries, sensitive data, public or guest access, high-volume automation, irreversible data migration, new identity models, agent actions, material licensing cost, unfamiliar platform capabilities and exceptions to an established standard. Routine changes that conform to approved patterns should move through normal peer review and automated controls.

Use two or three review tiers with published evidence requirements and response targets. A low-risk configuration change may need only a checklist and pull-request approval. A cross-system write involving regulated data may need security, data, integration and operations specialists. Risk tiering is JSBC Labs analysis, but it follows Salesforce's CoE guidance: Design Authorities should focus on architecture, duplicate structures, automation interactions, security and rare exceptions—not become absorbed by every minor detail.

Bring a decision brief, not a finished design

The review input should be short enough to understand and complete enough to decide. State the business outcome, affected capabilities, data classification, identities, expected volumes, latency and availability needs, systems of record, transaction boundaries, failure recovery, observability, cost drivers, migration approach and known constraints. Include the specific question that requires a decision. A diagram without these facts often communicates topology while hiding the trade-off.

For each material choice, show viable options and consequences. Flow versus Apex, event versus request-response, ingestion versus federation and custom build versus package are not competitions with universal winners. The review should test the option against functional and non-functional requirements, governor limits, security, operability, cost and team capability. Salesforce's architecture patterns explicitly recommend planning for requirements, volumes, limit implications, pattern selection and component interfaces before significant build investment.

Separate standards from judgement

Human reviewers should not spend expensive meeting time finding missing descriptions, hard-coded IDs, absent fault paths or untested permission changes. Put naming conventions, metadata rules, static analysis, tests, security scans and deployment validation in the delivery toolchain. Salesforce Well-Architected recommends automated pre-review checks so reviewers can concentrate on design and business logic, and it applies review rigor to declarative configuration as well as code.

Maintain written design standards for recurring choices: automation ownership, integration contracts, API versioning, data retention, access models, LWC composition, error handling, testing and release practices. Salesforce provides a design-standards template spanning data, automation, integrations, AI, user experience and application lifecycle management. A standard is valuable when teams can apply it without asking permission; the board should intervene when context makes the standard insufficient or contradictory.

Record the decision and its expiry conditions

The useful output is an Architecture Decision Record, not approved minutes. Capture context, the decision, alternatives considered, why they were rejected, consequences, accepted risks, owners and evidence. Add assumptions such as peak volume, licence count or source-system availability. Then define revisit triggers: a threshold, regulation change, product capability, incident pattern or target date that makes the decision no longer safe to inherit.

Salesforce Well-Architected recommends ADRs in version control and specifies business drivers, technical constraints, alternatives, consequences, technical debt and revisit triggers. Its compliance guidance adds residual risks, compensating controls and monitoring. This history prevents teams from reopening settled debates without new evidence, while making reversal legitimate when the original context changes. A decision should be durable, not permanent.

Make exceptions first-class architecture

Deadlines and legacy constraints sometimes justify departing from a standard. A hidden deviation becomes accidental architecture; a governed exception becomes a bounded risk. Record the exact rule being relaxed, business reason, affected scope, risk owner, compensating controls, monitoring, remediation work, target date and authority accepting the consequence. Do not label an exception 'temporary' without funding the path that ends it.

Review exceptions more closely than conforming designs, because they reveal where standards may be unrealistic or delivery incentives are misaligned. Repeated exceptions to the same rule should trigger a standards review, not a larger exception register. Salesforce's CoE guidance explicitly assigns the Design Authority responsibility for the rare cases where established guidelines need to be loosened or ignored; that responsibility includes learning from the pattern, not merely granting waivers.

Close the loop in production

An architecture decision is a hypothesis about how a system will behave. After release, compare the promised qualities with evidence: transaction latency, error and retry rates, limit consumption, queue age, support volume, adoption, licence utilisation, security findings and recovery performance. A post-implementation review should ask whether the decision worked, whether assumptions remained true and whether a new reusable pattern emerged.

Feed incidents and operational data back into ADRs and standards. Retire decisions when their components disappear, supersede them explicitly when the architecture changes and link follow-up debt to accountable owners. Salesforce frames Well-Architected as useful throughout a solution's life, not only during initial design. Governance that stops at approval protects a diagram; governance that learns from production protects the platform.

Measure decision flow, not meeting volume

Track time from a complete decision brief to an answer, percentage resolved without a meeting, rework caused by late review, exception age, recurring decision types, standards adopted, production incidents linked to missed risks and technical debt retired. Segment the measures by risk tier. A board can approve many items and still perform badly if teams wait weeks or the same design questions return every sprint.

The practical operating model is simple: publish standards, automate mechanical checks, review high-consequence choices early, return a written decision quickly and revisit it when evidence changes. Give one person authority to close each decision and distinguish blocking risks from recommendations. A Salesforce architecture review earns trust when it improves both safety and flow. If its primary output is permission to continue, the organisation has created a gate; if its output is understood trade-offs and accountable action, it has created architecture leadership.