Issacc.com

Platform Lifecycle and Deployment Architect Exam Prep - Planning

10 min read

Planning consists of 13% of total score in Salesforce Platform Lifecycle and Deployment Architect Exam. The topic covers ALM planning, governance framework & COE, Change Management, and Salesforce Seasonal Releases.

NOTE

Most of the content in this work was generated with the assistance of AI and carefully reviewed, edited, and curated by the author. If you have found any issues with the content on this page, please do not hesitate to contact me at support@issacc.com.

🗂 ALM Planning — People • Tech • Process

🎯 Objectives

  • Describe ALM processes & tools
  • Identify key roles
  • Map processes/tools/roles to scenarios

🔧 ALM Development Models (Overview)

ModelCore ToolsWhen to UseNotes
📦 Change Set DevelopmentChange Sets, SandboxesSmall/low-maturity orgsManual moves, limited delete/rename, track extras manually
📂 Org Development ModelGit, Salesforce DX, CLI, VS Code, Jira/Agile AcceleratorSource-driven teams & enterprisesBranch/PR, package.xml artifact, CI-friendly
🔀 Package Development ModelUnlocked Packages, Scratch Orgs, Git, CI/CDModular, multi-app, high maturityVersioned packages, isolated dev/test, easy upgrades

Quick pick →

Simple: Change Sets Team scale: Org Dev Modular/upgradeable: Package Dev

🧑‍🤝‍🧑 Roles (People)

  • Architect (solution design, standards)
  • Developers (code/config)
  • Admins (env & declarative)
  • Designer (UX/UI)
  • Business Analyst (BA) (requirements)
  • Quality Assurance (QA) (test/quality)
  • Project Manager (PM) (timeline/budget)
  • Release Manager (orchestrates releases)
  • Stakeholders (execs, managers, end users)

Stakeholder groups →

  • Executive leadership
  • Managers & super users
  • Dept leaders (Sales/Service/Marketing)
  • Core end users

⚙️ Development Model

📦 Change Set Development Model

  • Dev/Test in Dev sandboxes → integrate in Dev Pro → UAT in Full → Prod deploy
  • Use Outbound + Inbound change sets, Deployment Connection, Validation/Quick Deploy
  • Manual steps for unsupported metadata; deletions/renames handled manually; use Metadata Coverage report + custom change logs

📂 Org Development Model

  • Git = source of truth; DX project (sfdx-project.json), release artifact (package.xml)
  • Flow: Branch → Dev work (CLI retrieve/deploy) → PR/Review/Merge → Build artifact → Partial (UAT) → Full (staging) → Prod (validate + quick deploy)
  • Tooling: Salesforce CLI, VS Code Extensions, Jira/Agile Accelerator, change/run lists
  • Dev sandboxes for development; Dev Pro sandboxes for integration; Partial Copy sandboxes for UAT; Full sandboxes for staging/training
  • image

🔀 Package Development Model

  • Split into unlocked packages per module; all source in Git; Scratch Orgs for isolated dev/test
  • DX push/pull sync; CI runs tests on merges; install versions into sandboxes for UAT/staging → Prod
  • Benefits: independent, modularity, fewer merge conflicts, easier upgrades
  • Operate: Branch per module; Scratch Orgs for isolated dev/test; QA per package; CI/CD for build/deploy; PM + Release Manager coordinate

🔒 Environment Risks & Mitigations

Risk AreaCommon IssuesMitigations
CustomizationUnused features, complex deps, update conflictsGovernance rules, user-centered design, periodic reviews, refactor/remove dead code
Data Security & PrivacyUnauthorized access, non-complianceAuthZ/AuthN hygiene, Event Monitoring, Shield Encryption, sandbox data masking
GovernanceInconsistent practices, weak docs/testing, data qualityDesign standards, coding reviews, rigorous testing, data governance
Project ManagementPoor planning, vague requirements, scope creepClear plan/scope/resources, stakeholder engagement, Change Control Board (CCB)
DevelopmentTech debt, resource limits, integration failuresRegular refactor, impact-based prioritization, controlled integration testing
TestingLow coverage, manual errors, shared org collisionsComprehensive strategy, automation where apt, masked test data, separate sandboxes/scratch orgs

AuthN vs AuthZ

AuthN - Authentication, verify who you are (your identity)

AuthZ - Authorization, verify what you are allowed to do (your permission)

One-sandbox anti-pattern → Causes collisions and flaky tests; prefer per-stream sandboxes or scratch orgs.

🏛 Governance Framework & Center of Excellence (COE)

What/Why

  • Governance = minimal processes to deliver outcomes on time/quality; aligns business + IT; reduces risk; boosts velocity/compliance/innovation
  • Maturity: Non-existent → Emerging → Practicing → Leading
  • Center of Excellence (COE) (cross-functional experts, standards)
  • Change Management (CM) (collect → prioritize → approve → roll out)
  • Org Strategy (org design)
  • Technical Governance (principles/standards)

Center of Excellence (COE) Essentials

  • People/Roles:
    • Exec Sponsors
    • Program Owners
    • Steering Committees (Business/Architecture/Release/Change/Support)
    • SMEs/Power Users
  • Charter: decision rights, cadence, deliverables; run Program/Exec/Focus meetings
  • Design Standards: naming, descriptions with links/deps, Apex/trigger annotations, doc templates and audits
  • Release/Deployment: predictable cadence, comms, pre-release sandboxes, stages (Dev → QA → UAT → Staging → Prod)
  • Backlog Prioritization: transparent tooling (Jira/Confluence/Slack), publish decisions/timelines

COE models →

  • Consolidated (work in single platform with share approach)
  • Federated (independent group operation, maintaining unified approach)
  • Confederated (operate independently using separate Salesforce instances)
  • Hybrid

🔁 Change Management (CM)

  • Types: Org/process shifts • Feature additions • Salesforce seasonal changes
  • Process: Initiate/Plan (vision, roadmap) → Operationalize (build/config/deploy, drive adoption) → Validate (audit data, metrics, behavior updates)
  • Key Users:
    • User community
    • Decision makers (e.g., Enterprise Architect)
    • CCB/Steering
    • Executive Sponsor
  • Good CM: simple execution strategy, cross-functional alignment, impact sizing, comms/training, power-user follow-up

🗓 Salesforce Seasonal Releases (Spring • Summer • Winter)

Readiness Essentials

  • Preview sandboxes upgraded ~4–6 weeks pre-prod; manage refresh timing to stay preview
  • Check Sandbox Preview Guide; maintain at least one preview sandbox
  • Release Notes: identify Quick Wins (auto-enabled) vs Low-Effort items; engage super users; plan comms
  • Pre-release orgs: early peek, 3-4 weeks before sandbox preview starts (no customizations though)
  • Testing: prioritize UX impacts and custom code; run unit/integration/functional/UAT/performance; prefer API tests over brittle UI; mind governor limits

Cycle → Mark calendar → Engage community → Preview in sandbox → Review notes → Train/communicate → Roll out

🧪 Types of Testing

  • Unit (smallest code units)
  • Integration (external touchpoints)
  • Functional (against requirements)
  • UAT (end-user acceptance)
  • Performance (scale/limits)
  • Considerations: sandbox creation/refresh, API>UI tests, generate masked test data, don’t automate perf tests, retest both sides of integrations, rebuild Classic-only tests

🎯 Key Takeaways

  • Model fit: 📦 Change Set (simple) • 📂 Org Dev (team scale) • 🔀 Package Dev (modular)
  • Triad: People + Tools + Process must match maturity and complexity
  • Governance/COE drives velocity, quality, compliance, and alignment
  • CM + Testing + Release Readiness = fewer surprises, faster value

📈 Flow Charts

1) Pick the Right ALM Development Model

flowchart TD
  A([Start]) --> B{Org maturity & complexity high?}
  B -- Yes --> C{Modularity/independent releases needed?}
  C -- Yes --> PKG[🔀 Package Dev<br/>Unlocked packages + Scratch Orgs + CI/CD]
  C -- No --> D{Source control + branching required?}
  D -- Yes --> ODM[📂 Org Dev Model<br/>Git + DX + package.xml]
  D -- No --> CSD[📦 Change Set Dev<br/>Change Sets + Sandboxes]
  B -- No --> E{Small/simple changes?}
  E -- Yes --> CSD
  E -- No --> F{Team collaboration/PR reviews?}
  F -- Yes --> ODM
  F -- No --> CSD

2) Environment Risk → Mitigation Router

flowchart TD
  A([Risk Identified]) --> B{Category?}
  B -- Customization --> C[Adopt governance rules<br/>User-centered design<br/>Review & refactor]
  B -- Data Security --> D[Strong AuthN/AuthZ<br/>Event Monitoring<br/>Shield Encryption<br/>Sandbox data masking]
  B -- Governance --> E[Design standards<br/>Coding reviews<br/>Rigorous testing<br/>Data governance]
  B -- Project Mgmt --> F[Clear plan/scope/resources<br/>Stakeholder engagement<br/>CCB to control scope]
  B -- Development --> G[Refactor tech debt<br/>Impact-based prioritization<br/>Controlled integration tests]
  B -- Testing --> H[Comprehensive strategy<br/>Automate where apt<br/>Separate envs/scratch orgs]

3) Build a Governance Framework & COE

flowchart TD
  A([Start]) --> M{Assess maturity}
  M -- Non/Emerging --> B[Define minimal processes]
  M -- Practicing/Leading --> B
  B --> C[Form COE<br/>Cross-functional roles + charter]
  C --> D[Set design standards<br/>Naming, descriptions, code annotations]
  D --> E[Backlog governance<br/>Transparent tooling + cadence]
  E --> F[Release & deployment strategy<br/>Dev→QA→UAT→Staging→Prod]
  F --> G[Change Management process<br/>Collect→Prioritize→Approve→Roll out]
  G --> H[Measure outcomes<br/>Adoption, quality, budget, AARs]
  H --> I{Improve?}
  I -- Yes --> B
  I -- No --> J([Operate & Monitor])

4) Seasonal Release Readiness (Spring • Summer • Winter)

flowchart TD
  A([Upcoming Salesforce Release]) --> B[Mark calendar & read Release Notes]
  B --> C{Have preview sandbox?}
  C -- Yes --> D[Plan tests in preview sandbox]
  C -- No --> E{Within preview window?}
  E -- Yes --> F[Refresh/retain at least one sandbox on preview]
  E -- No --> G[Use pre-release org for early look]
  D --> H[Prioritize Quick Wins & low-effort items]
  H --> I[Run unit/integration/functional/UAT/perf tests]
  I --> J[Communicate & train users]
  J --> K{Prod upgraded?}
  K -- Yes --> L[Deploy internal release aligned to seasonal]
  K -- No --> M[Stage changes; wait for prod upgrade]

📚 Flashcards

Recent Notes

Graph View