10.1 Application Lifecycle Management (ALM) Stages & Governance

10.1 Application Lifecycle Management (ALM) Stages & Governance

In an enterprise Salesforce environment, delivering business value requires far more than technical proficiency with Flow Builder, custom objects, or Lightning App Builder. It demands a rigorous, disciplined framework for designing, building, validating, and deploying metadata changes without disrupting active business operations. This disciplined methodology is known as Application Lifecycle Management (ALM).

Without structured ALM processes, organizations inevitably descend into chaotic development patterns: modifying configuration directly in production, overwriting peer configurations, introducing regressions, triggering unintended customer-facing automated notifications, and failing regulatory compliance audits (such as Sarbanes-Oxley / SOX). For the Salesforce Certified Platform App Builder, understanding the formal stages of ALM, enterprise governance models, release train cadences, and environment management is essential for architecting reliable, scalable solutions.

---

The Anti-Pattern: Developing Directly in Production

One of the most dangerous misconceptions in cloud development is that declarative "point-and-click" changes are inherently safe to configure directly in a live production environment. In reality, modifying production metadata directly introduces critical organizational risks:

1. Unintended Automation Triggers: Activating a Record-Triggered Flow or validation rule in production can immediately lock thousands of database records, cause bulk integrations to fail, or send erroneous email alerts to active customers.
2. Configuration Overwrites & Race Conditions: When multiple administrators or developers make simultaneous changes in production without source tracking, they silently overwrite one another's work without reliable version history; Setup Audit Trail alone is not a source-control or release-review process.
3. Data Inconsistency and Corruption: Modifying picklist values, required field properties, or formula dependencies on live records can break reporting pipelines and corrupt data integrity across historical records.
4. Audit and Compliance Violations: Organizations may require segregation of duties, approvals, and audit records under their own change policies. Determine the controls applicable to the organization rather than treating every named law as one universal Salesforce deployment rule.

---

The Six Formal Stages of Salesforce ALM

Salesforce defines a standard six-stage lifecycle that governs the progression of changes from concept to live production availability:

[1. Plan] ──► [2. Develop] ──► [3. Test] ──► [4. Build Release] ──► [5. Test Release] ──► [6. Release]

Stage 1: Plan

Every initiative begins with planning. During this stage, business stakeholders, product owners, enterprise architects, and app builders collaborate to translate business needs into detailed technical specifications:

• Requirements Gathering & User Stories: Capturing user requirements with clear, testable acceptance criteria.
• Architectural & Security Design: Determining whether requirements should be solved declaratively (Flow, Validation Rules) or programmatically (Apex, LWC), evaluating governor limits, and assessing data security implications.
• Backlog Prioritization: Categorizing user stories into release cycles (major releases, minor enhancements, or quick wins).
• Environment Planning: Identifying which sandbox tiers will be required for development, integration, and testing.

Stage 2: Develop

Development takes place in isolated development environments—typically Developer Sandboxes or modern Scratch Orgs:

• Isolated Construction: Builders configure custom fields, create Record-Triggered Flows, design Lightning pages, or write Apex code without impacting any other team member's workspace.
• Source Tracking & Version Control: Utilizing modern source control (such as Git) or change tracking to maintain an auditable record of every granular metadata modification.
• Controlled Test Data: Developer environments usually use synthetic or approved masked data. Sandbox type, copying behavior, permissions, and post-copy safeguards must be reviewed; a sandbox is not an automatic privacy guarantee.

Stage 3: Test

Once development is completed within an isolated sandbox, the author conducts initial verification:

• Unit Testing: Testing individual components in isolation against expected positive and negative input values.
• Apex Unit Tests: Executing Apex test classes to verify that all programmatic code satisfies the mandatory platform requirement of at least 75% test code coverage (with 100% pass rates).
• Boundary & Validation Testing: Verifying that edge-case scenarios, validation rules, and flow fault paths behave as designed.

Stage 4: Build Release

In this pivotal aggregation stage, individual features developed across disparate sandboxes are consolidated into a single cohesive release package:

• Metadata Bundling: Collecting all modified custom fields, flows, layouts, permission sets, and classes into a single deployment artifact (such as an Inbound Change Set, a Salesforce DevOps Center work item, or a version-controlled deployment branch).
• Dependency Resolution: Identifying and resolving missing metadata dependencies (e.g., ensuring a custom field referenced by a Flow is explicitly included in the deployment package).
• Integration Sandbox Deployment: Promoting the release artifact into a shared integration environment (such as a Developer Pro or Partial Copy Sandbox) to resolve merge conflicts and verify that components authored by different builders function harmoniously.

Stage 5: Test Release

The integrated release package is subjected to comprehensive, real-world evaluation in an environment that closely replicates production (such as a Partial Copy Sandbox or Full Sandbox):

• User Acceptance Testing (UAT): Business end-users execute realistic end-to-end operational workflows to verify that the release satisfies business acceptance criteria.
• System Integration Testing (SIT): Validating bi-directional data exchanges and API callouts with external enterprise systems (e.g., ERP, billing gateways, marketing automation platforms).
• Performance & Load Testing: Executing bulk data operations to verify that batch jobs and automations do not breach governor limits under heavy transaction volumes.
• Regression Testing: Verifying that new features have not inadvertently broken existing platform functionality or reporting dashboards.

Stage 6: Release

The final stage is the authorized deployment of the tested metadata package into the live Production organization:

• Pre-Deployment Execution: Completing any manual prerequisite setup steps that cannot be deployed via metadata APIs (e.g., enabling platform feature toggles, configuring third-party connected app secrets).
• Metadata Deployment: Executing the deployment via change sets or CI/CD pipelines, typically during a scheduled maintenance window with minimal active user traffic.
• Post-Deployment Execution: Running post-deployment configuration tasks, such as activating flows, assigning permission sets, seeding production reference data, and verifying integration endpoints.
• Hypercare & Training: Providing immediate real-time support for end-users, monitoring debug logs for unhandled exceptions, and conducting user enablement sessions.

---

Enterprise Governance Frameworks

As organizations expand their Salesforce footprint across multiple business units, robust governance frameworks become essential to manage competing priorities, maintain platform integrity, and enforce compliance.

Center of Excellence (CoE)

A Center of Excellence (CoE) is a cross-functional leadership body that defines the strategic direction, architectural standards, and operational guidelines for the Salesforce platform across the entire enterprise.

• Composition: Executive sponsors, enterprise architects, IT leadership, business unit stakeholders, security officers, and lead Salesforce administrators.
• Core Responsibilities:
  • Establishing enterprise architecture patterns (e.g., "Clicks-Before-Code" standards, naming conventions).
  • Managing the overarching enterprise roadmap and prioritizing large-scale capital investments.
  • Enforcing data governance, master data management (MDM), and compliance policies (GDPR, HIPAA).
  • Defining sandbox management strategies and DevOps tooling standards.

Change Advisory Board (CAB) / Change Control Board (CCB)

While the CoE focuses on long-term strategy, the Change Advisory Board (CAB)—also called the Change Control Board (CCB)—is an operational governance committee responsible for reviewing, scheduling, and approving day-to-day release candidates before they are deployed to production.

• Composition: Release managers, lead architects, QA leads, business analysts, and system administrators.
• Core Responsibilities:
  • Evaluating release risk: Assessing potential business disruption, downtime requirements, and technical complexity.
  • Reviewing deployment dependencies and pre/post-deployment checklists.
  • Verifying UAT sign-offs and regression testing results.
  • Formulating and approving contingency rollback plans in the event of deployment failure.
  • Authorizing deployment windows (e.g., off-peak weekend release slots).

---

Release Trains & Deployment Cadences

Enterprise Salesforce teams organize their deployments into predictable, rhythmic cycles known as Release Trains. Instead of releasing features whenever they happen to be completed, teams adhere to strict calendar schedules:

---

Comparison: ALM Stages, Environments & Deliverables

---

Exam Traps and Architectural Best Practices

• Trap: Conflating the CoE and CAB. The Center of Excellence sets enterprise-wide vision, architectural principles, and long-term strategy. The Change Advisory Board reviews specific technical release manifests, evaluates immediate operational risk, and approves deployment schedules.
• Trap: Premature Testing in the ALM Lifecycle. Unit testing occurs in Stage 3 (Test) within isolated developer sandboxes. However, formal User Acceptance Testing (UAT) and end-to-end integration testing do not occur until Stage 5 (Test Release) within a consolidated Partial Copy or Full Sandbox that mirrors production data volume and integration endpoints.
• Trap: The Forgotten Hotfix Backport. When an emergency hotfix is deployed to production to resolve a critical operational failure, administrators frequently forget to backport that exact fix into active, in-flight Developer sandboxes. When the next scheduled major release deploys from those sandboxes to production, it overwrites the hotfix with stale metadata, re-introducing the critical defect into production!

Official Source Check

Checked October 19, 2026: Sandbox types and intended testing uses.