Issacc.com

Platform Lifecycle and Deployment Architect Exam Prep - Planning

11 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) • BA (requirements) • QA (test/quality) • 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

⚙️ Processes (By Model)

📦 Change Set Development

  • 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 + custom change logs

📂 Org Development Model

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

🔀 Package Development Model

  • Split into unlocked packages per module; all source in Git; Scratch Orgs per dev/test
  • DX push/pull sync; CI runs tests on merges; install versions into sandboxes for UAT/staging → Prod
  • Benefits: modularity, fewer merge conflicts, easier upgrades

🔒 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 MgmtPoor 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

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

🏛 Governance Framework & 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

Categories

  • COE (cross-functional experts, standards) • Change Management (collect→prioritize→approve→roll out) • Org Strategy (org design) • Technical Governance (principles/standards)

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 • Federated • Confederated • (or 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 (no customizations)
  • 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

🧪 Testing Cheat Sheet

  • 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

🧭 Scenarios → Recommended Approaches

🌍 Cross-Region Bank (EMEA + APAC, complex integration/security)

  • Use: 📂 Org Dev Model with Git, DX, CLI, VS Code; Dev sandboxes per team; Dev Pro for integration; Partial UAT; Full staging/training
  • Manage: Jira/Agile Accelerator for requirements & defects; regular cross-region sync

🇪🇺 Financial Suite (finance tool + HCM + analytics; upgradeable, modular)

  • Use: 🔀 Package Dev Model with independent unlocked packages
  • Operate: Branch per module; Scratch Orgs for isolated dev/test; QA per package; CI/CD for build/deploy; PM + Release Manager coordinate

🛠 ISP: Customization + Security + Governance Gaps

  • Findings: Unused features, unclear object/field purpose, unauthorized data access
  • Mitigate: User-centered design; enforce design standards (descriptions/help text); Profiles/PermSets/FLS; Shield Encryption; clean up redundant customizations

🧳 IT Request App: Unknown Requirements, Scope Creep, Single Sandbox

  • Approach: Agile to iterate requirements; CCB to control scope; Scratch Orgs for isolated testing (license constraints); avoid one-sandbox model

🔄 Seasonal Release Alignment (Spring)

  • Issue: Internal major release conflicts with seasonal upgrade; sandbox timing off
  • Plan: Create unified release calendar; refresh Full ~6 weeks before go-live for preview testing; deploy after prod is upgraded; train/alignment for all teams

🧱 Metadata Deploy Mismatch (Dev Pro → Partial UAT)

  • Root Cause: Version skew (preview vs non-preview)
  • Fix: Align sandbox versions; review Release Notes for auto-enabled/manual features; refresh during preview window; run regression in upgraded sandbox

🎯 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

🔑 ALM Roles & Stakeholders

⚠️ Environment Risks & Mitigation

🏛 Governance & COE

🔁 Change Management

🌱 Salesforce Seasonal Releases

🧭 Scenario-based Quick Picks

Recent Notes

Graph View