Governance Model

Governance determines how decisions get made, who makes them, and how changes flow through the organization. In CTA scenarios, weak governance is a common root cause of failed implementations. The balance matters: too much governance stalls delivery, too little creates chaos.

Architecture Review Board (ARB)

The ARB ensures architectural decisions align with organizational standards, long-term strategy, and technical best practices.

ARB Structure

Role	Responsibility	Typical Participant
Chair	Leads meetings, ensures decisions are documented	Enterprise Architect or CTA
Voting Members	Evaluate proposals, make decisions	Technical Architects, Lead Developers
Subject Matter Experts	Provide domain-specific input when needed	Security, Integration, Data specialists
Requestors	Present proposals for review	Project teams, feature owners
Executive Sponsor	Breaks ties, provides strategic alignment	VP of Engineering or CTO

ARB Meeting Cadence

Meeting Type	Frequency	Purpose
Regular Review	Bi-weekly or monthly	Review pending architectural proposals
Emergency Review	Ad hoc	Critical issues requiring immediate architectural decisions
Quarterly Strategy	Quarterly	Review architectural roadmap, standards updates
Annual Review	Annually	Technology radar update, standards refresh

What Goes Through the ARB

• New integration patterns or middleware selection
• AppExchange package adoption (using the vendor evaluation scorecard)
• Data model changes affecting more than one application area
• New technology adoption (LWC components, OmniStudio, Agentforce (formerly Einstein Copilot))
• Cross-cloud or multi-org architectural decisions
• Changes to the org’s security model
• Significant automation changes (new triggers, complex flows)

ARB Review Process Flow

Figure 1. The fast path (matching an existing approved pattern) is what good standards governance enables. Every ARB approval that becomes a documented ADR reduces future ARB overhead by expanding the set of pre-approved patterns teams can use without review.

Lightweight ARB

Not every decision needs a formal ARB session. Define clear criteria for what qualifies (new patterns, cross-domain impact, vendor selection) versus what the tech lead can decide within existing standards. Over-governing slows delivery; under-governing causes drift.

What Does NOT Need ARB Approval

• Bug fixes within existing architecture
• Configuration changes within established patterns
• Minor field additions to existing objects
• Report and dashboard creation
• Standard Flow modifications within the one-automation-per-object pattern

Change Advisory Board (CAB)

The CAB reviews and approves changes before they are deployed to production.

CAB vs ARB

Aspect	ARB	CAB
Focus	Design decisions	Deployment decisions
When	Before building	Before deploying
Question	”Is this the right solution?"	"Is this safe to deploy?”
Outcome	Architecture approval	Change approval
Participants	Architects, tech leads	Release managers, QA, ops

Change Classification

Change Type	Risk Level	Approval Process	Example
Standard	Low	Pre-approved, no CAB review	Field label change, report creation
Normal	Medium	CAB review required	New automation, integration change
Emergency	High/Critical	Expedited approval (post-implementation review)	Production bug fix, security patch
Major	High	Full CAB + ARB review	New cloud implementation, data migration

Change Management Flow

Every change to a Salesforce org, whether code, configuration, or data, follows a lifecycle from request to verification. This flow integrates the ARB and CAB roles.

Figure 2. Emergency changes bypass CAB review but require a mandatory post-implementation review within 48 hours. A pattern of frequent emergencies signals a systemic gap in testing or release planning, and both are architectural concerns the CTA must surface and address.

Emergency Changes

Emergency changes bypass the standard CAB review process but are not exempt from governance. Every emergency change must have a post-implementation review within 48 hours. If emergencies become frequent, that signals a systemic problem with testing, architecture, or release planning.

RACI Matrix

A RACI matrix clarifies roles and responsibilities across key governance activities.

Salesforce Governance RACI

Activity	CTA/EA	Dev Lead	Admin Lead	PM	Business Owner
Architecture decisions	A, R	C	C	I	I
Code standards	A	R	I	I	-
Declarative standards	A	C	R	I	-
Change requests	C	R	R	A	R
Production deployments	C	R	R	A	I
Incident management	C	R	R	I	I
Vendor evaluation	A, R	C	C	C	R
Data governance	C	C	C	I	A, R
User provisioning	I	I	R	I	A
Release planning	C	R	R	A	C

R = Responsible (does the work), A = Accountable (final decision), C = Consulted, I = Informed

CTA Exam Signal

Including a RACI matrix (even a simplified version) in the CTA presentation shows the review board that you consider organizational structure, not just technology. This separates a Technical Architect from a Chief Technical Architect.

Salesforce Center of Excellence (CoE) Model

A CoE is the organizational structure that governs Salesforce use across the enterprise.

CoE Models

Figure 3. The Hybrid CoE separates what must be consistent (architecture standards, shared integrations) from what must be fast (BU delivery). This is the model most CTA review boards expect to see recommended for medium-to-large enterprise Salesforce implementations.

Model	Strengths	Weaknesses	Best For
Centralized	Consistent standards, no duplication, strong governance	Bottleneck, slow response, disconnected from business	Small to medium orgs with one Salesforce instance
Federated	Business unit autonomy, fast delivery, local expertise	Inconsistent standards, duplication of effort, drift	Large enterprises with independent business units
Hybrid	Balanced control and agility, shared standards with local delivery	Complex to operate, requires strong leadership	Large enterprises needing consistency with business agility

CTA Recommendation Pattern

In most CTA scenarios, the Hybrid CoE fits best: the central team owns architecture, standards, and shared services while business unit teams own delivery. The review board values this nuanced recommendation over a one-size-fits-all answer.

Governance Framework Overview

The governance framework connects strategic direction, architectural standards, change control, and operational delivery.

Figure 4. ARB and CAB serve distinct purposes at different points in the lifecycle: ARB governs what gets built, CAB governs what gets deployed. Conflating the two into a single committee creates approval bottlenecks and confusion about decision authority.

Architecture Decision Records (ADRs)

ADRs capture the rationale behind significant architectural decisions. They are lightweight but valuable over time.

ADR Template

# ADR-{NUMBER}: {Title}

## Status
Proposed | Accepted | Deprecated | Superseded

## Context
What is the issue that we're seeing that is motivating this decision?

## Decision
What is the change that we're proposing and/or doing?

## Consequences
What becomes easier or more difficult to do because of this change?

## Alternatives Considered
What other options were evaluated and why were they rejected?

When to Write an ADR

• Choosing between platform approaches (Flow vs Apex for a major automation)
• Selecting an AppExchange package
• Designing an integration pattern
• Choosing a data model approach
• Changing the development or deployment process
• Adopting a new technology or tool

Standards and Policies

Technical Standards to Define

Standard Area	What to Define	Example
Naming conventions	Objects, fields, classes, flows	Account_Territory_Assignment_Flow, AccountService.cls
Code standards	Apex style guide, LWC patterns	Apex Enterprise Patterns, ESLint config
Automation standards	One flow per object, error handling	Master flow pattern, fault path template
Integration standards	Named Credentials, error handling	Circuit breaker pattern, retry policy
Security standards	FLS/CRUD enforcement, sharing model	Always check CRUD in Apex, no without sharing
Data standards	Required fields, picklist values	Data dictionary, picklist governance
Testing standards	Coverage targets, assertion rules	85% coverage, meaningful assertions

Policy Examples

Deployment Policy:

• All production deployments require successful UAT sign-off
• Deployment windows: Tuesdays and Thursdays, 6 PM - 10 PM (off-peak)
• Emergency deployments require CAB chair approval
• All deployments must include a rollback plan

Data Policy:

• No production data in development sandboxes without masking
• PII fields must be encrypted in transit and at rest
• Data retention policies must be documented per object
• Bulk data operations require ARB notification

Compliance Considerations

Regulatory Frameworks

Framework	Key Requirements for Salesforce	Affected Industries
GDPR	Right to be forgotten, data portability, consent management	Any org with EU data subjects
HIPAA	PHI encryption, access controls, audit logging. Salesforce offers a Business Associate Agreement (BAA) for Shield and Health Cloud - required before storing PHI.	Healthcare, health insurance
SOX	Financial controls, audit trails, segregation of duties	Public companies
PCI-DSS	Cardholder data protection, access controls	Payment processing
CCPA	Consumer data rights, opt-out mechanisms. Implement via Privacy Center for opt-out/do-not-sell workflows, Data Subject Access Requests (DSARs) for consumer data requests, and automated data deletion workflows. Similar to GDPR but opt-out (not opt-in) model.	Any org with CA consumers
FedRAMP	Government cloud requirements	Government contractors

Compliance Implementation in Salesforce

Requirement	Salesforce Solution
Data encryption	Shield Platform Encryption
Audit logging	Shield Event Monitoring, Field Audit Trail
Access controls	Profiles, Permission Sets, sharing rules
Data retention	Archival strategy, Big Objects
Right to be forgotten	Data deletion processes, anonymization
Segregation of duties	Profile restrictions, approval processes
Compliance reporting	Event Monitoring, custom audit objects

Compliance is Non-Negotiable

If the customer is in a regulated industry, compliance requirements override all other architectural preferences. Do not recommend a technically superior solution that violates compliance. Document compliance requirements as architectural constraints and design within them.

Data Governance

Data Governance Framework

Component	Description	Owner
Data Dictionary	Definitive list of all objects, fields, and their business meaning	Data Architect
Data Quality Rules	Validation rules, duplicate rules, data cleansing processes	Admin Lead
Data Ownership	Which business unit owns each data domain	Business Owners
Data Retention	How long data is kept and when it is archived or deleted	Compliance + Business
Data Access	Who can see, edit, and delete each data domain	Security Architect
Data Lineage	Where data comes from and where it flows	Integration Architect

Metadata Governance

• Track all metadata changes in source control (not just code; Flows, objects, and fields too)
• Review metadata changes before deployment. Declarative changes need review too.
• Monitor metadata growth: custom object count, field count, automation count
• Clean up unused metadata regularly: inactive flows, unused fields, orphaned classes

Related Topics

• CI/CD & Deployment: How governance gates fit into deployment pipelines
• Environment Strategy: Environment access governance
• Risk Management: Governance as risk mitigation
• Testing Strategy: Testing governance and quality gates
• Decision Guides: Governance structure decision flowcharts
• Security: Security governance and compliance
• Best Practices: Solution architecture governance

Sources

• Salesforce Architects: Governance Framework
• Salesforce Well-Architected: Trusted Principle
• TOGAF: Architecture Governance
• Michael Keeling: Design It! - Architecture Decision Records
• Salesforce Help: Shield Platform Encryption
• Salesforce Help: Event Monitoring
• Salesforce Help: Introduction to Governance Whitepaper
• Salesforce Architects: Well-Architected - Intentional
• CTA Study Groups: Community governance patterns for enterprise Salesforce