In my previous SF Ben article, How to Start Thinking Like a Salesforce Architect, I wrote about mindset – the shift from delivering features to exercising architectural judgment. But thinking like an architect is only the beginning. Architectural decisions endure only when their intent is communicated clearly, understood beyond purely technical audiences, and revisited deliberately as the platform evolves. Without structure, even well-reasoned decisions erode under delivery pressure.
This is where a Salesforce Design Authority becomes essential – not as a gatekeeper, but as a shared forum for architectural stewardship. When done well, it protects architectural intent while allowing teams to move with confidence.
The Real Problem: Architectural Drift
Most Salesforce technical debt is not caused by poor engineering or lack of skill. It emerges when reasonable decisions are made under pressure and never revisited. Small compromises accumulate. Local optimizations become global constraints. Over time, urgency replaces intent.
Design Authority exists to counter this drift by making architectural decisions visible, deliberate, and durable. The diagram below illustrates how architectural intent erodes under delivery pressure when decisions remain implicit.
Design Authority and Technical Debt
Technical debt is rarely intentional – but it becomes inevitable when decisions are implicit, and ownership is unclear.
The difference between healthy and fragile Salesforce platforms is not the absence of debt, but whether that debt is consciously accepted or accidentally accumulated.
Accidental vs. Intentional Technical Debt
| Accidental Technical Debt | Intentional Technical Debt |
| Decisions made implicitly | Decisions discussed explicitly |
| Trade-offs forgotten | Trade-offs recorded |
| Surprises emerge late | Impacts understood early |
| Hard to unwind | Revisited deliberately |
Design Authority enables intentional technical debt by creating a forum where trade-offs are surfaced early, acknowledged openly, and revisited as conditions change.
What a Salesforce Design Authority Is (and Isn’t)
Design Authority is often misunderstood for several reasons:
- It is not a delivery gate.
- It is not a code review board.
- It is not a replacement for solution ownership.
Instead, it is a central forum where architectural decisions with long-term impact are discussed and aligned – before they become constraints.
| Design Authority Does | Design Authority Does Not |
| Review changes with enterprise or cross-team impact | Review every line of code or configuration |
| Guide architectural trade-offs and decision intent | Act as a delivery gatekeeper or approval bottleneck |
| Reinforce shared patterns and long-term consistency | Override the solution architects’ design ownership |
| Make architectural decisions visible and revisitable | Slow teams down with process for its own sake |
| Provide a forum to explain trade-offs in business terms | Operate as a centralized delivery function |
| Support shared understanding across technical and non-technical stakeholders | Function as a Center of Excellence, owning the delivery execution |
Design Authority works best when architectural intent is made explicit once and trusted thereafter.
Applying the Right Questions to Salesforce Trade-Offs
Design Authority does not enforce a single set of rules. It adapts its questions to the type of decision being made.
A Concrete Example: Permission Sets vs. Profiles
Access decisions are about identity, scalability, and clarity – not convenience.
Questions Design Authority should surface include:
- Is access driven by role, capability, or context?
- How will this model scale as teams and identities grow?
- Will someone be able to understand and troubleshoot access six months from now?
Profiles often proliferate to solve short-term needs. Design Authority helps teams pause and choose models that remain understandable as the org grows.
Ownership and Accountability: Making Design Authority Stick
Design Authority only works when ownership is explicit. The Lead Platform Architect is accountable for architectural coherence – not because they decide everything alone, but because architectural accountability cannot be diffused without disappearing.
This clarity prevents Design Authority from becoming advisory or optional and ensures architectural decisions survive delivery pressure and team changes.
A Practical Design Authority Team Structure (Flexible by Design)
At enterprise scale, Design Authority often includes domain perspectives – data, integration, security – alongside Salesforce technical leadership. The forum is typically owned by a Lead Platform Architect, who is accountable for architectural coherence.
This structure scales both up and down. In smaller Salesforce teams, these roles often collapse into one or two individuals. What matters is not the number of boxes on an org chart, but that architectural ownership is explicit, trade-offs are discussed early, and decisions are recorded rather than rediscovered later.
Starting Where No Design Authority Exists
Starting a Design Authority where none exists is as much about credibility as it is about structure. Teams that succeed rarely begin with formal mandates. They start small – by consistently showing up early to important decisions, framing trade-offs in business terms, and helping delivery teams avoid rework.
Over time, executive sponsorship follows when leaders see fewer late-stage surprises and more predictable outcomes.
Common starting moves include:
- Anchoring Design Authority discussions on visible pain points, such as rework, missed releases, or recurring architectural escalations
- Positioning Design Authority as a confidence enabler, not a speed inhibitor
- Securing explicit support from a single executive sponsor before scaling the model
- Earning authority through decision quality before formalizing governance
Where Design Authority Fits in Delivery
Design Authority follows decision gravity, not calendar cadence.
Routine decisions may be handled asynchronously. Higher-impact trade-offs require focused discussion. Escalation occurs only when the organization is unwilling to consciously accept the implications of a decision.
In reality, Design Authority and delivery priorities will occasionally collide – especially near release deadlines. When this happens, the goal is not to “win” the argument, but to make the trade-off explicit.
Effective Design Authorities plan for these moments by agreeing in advance how emergency overrides will work: who can authorize them, how the risk will be communicated, and how the decision will be revisited post-release. This preserves delivery momentum without silently converting short-term urgency into long-term architectural constraint.
Tooling That Supports Design Authority
Design Authority is a discipline, not a tool – but it integrates naturally into existing workflows.
Teams often capture outcomes as lightweight decision records alongside code or documentation. The emphasis is not on formality, but on preserving intent beyond the moment a decision is made.
In practice, “lightweight” does not mean vague. Many teams start with a deliberately small structure – often no more than a few lines – to capture the essence of a decision without slowing delivery. A simple starting point looks like this:
- Decision: What was decided, and at what scope
- Rationale: Why this option was chosen over alternatives
- Implications: What this decision enables – and what it consciously constrains
This level of documentation is often sufficient to ensure decisions aren’t rediscovered, re-debated, or unintentionally reversed as teams evolve and delivery pressure increases.
Some organizations complement this with metadata scanning or change-analysis tools to surface changes with architectural impact. The specific tooling matters less than the consistency with which decisions are made visible and revisitable.
Signals Your Design Authority Is Working
- Architectural questions are raised early
- Patterns emerge naturally rather than being enforced
- Exceptions are documented instead of rediscovered
- New team members understand why decisions exist
- The platform evolves with confidence, not fear
While many signals of Design Authority effectiveness are qualitative, teams often begin to see measurable outcomes as the practice matures. Common indicators include reduced late-stage architectural rework, fewer emergency escalations during release cycles, and improved predictability of delivery timelines.
Used carefully, these measures help translate architectural stewardship into outcomes that resonate with executive stakeholders – without turning Design Authority into a reporting or compliance exercise.
Final Thoughts
Design Authority is not bureaucracy. It is what architectural maturity looks like when Salesforce platforms grow beyond individual projects. It does not slow teams down – it helps them move with confidence, because architectural intent is clear, shared, and protected.
This article focuses on architectural decision-making and stewardship – not on Centers of Excellence structures or organizational politics, which vary widely across enterprise contexts. Thinking like a Salesforce architect is only the beginning. Design Authority is how that thinking survives delivery.
