Issacc.com

Platform Lifecycle and Deployment Architect Exam Prep - System Design

13 min read

System Design consists of 15% of total score in Salesforce Platform Lifecycle and Deployment Architect Exam. The topic covers agile development tools, org strategy, sandbox strategy, and deployment strategy.

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.

🎯 System Design — Agile Tools & Salesforce (Obsidian-Ready Summary)

TL;DR

Agile tools (Salesforce DX + Agile PM suites) boost speed, visibility, and quality.
Org strategy (Single vs Multi) depends on integration + standardization needs.
Sandboxes: pick Dev / Dev Pro / Partial / Full to fit dev, test, training, staging.
Deployments: combine governance + tests + rollback with DX/CLI + CI/CD.

✅ Learning Goals (Checklist)

  • Identify agile-supporting tool types
  • Explain Salesforce DX features + advantages
  • Explain agile PM tools features + advantages
  • Describe benefits of agile tools for a given business need
  • Compare single.org vs multi.org strategies
  • Select sandbox strategy for multi-stream dev, training, staging, hotfixes
  • Recommend deployment components + tools for scenarios

🚀 Why Agile Tools Matter (Advantages)

  • Visibility: real-time status, boards, burndown charts, analytics
  • Collaboration: shared backlogs, comments, chat, docs
  • Centralization: single source of truth for artifacts & code
  • Scalability & Predictability: sprints with defined scope/time/cost
  • Quality: CI, automated tests, fast feedback loops, fewer defects
  • Integration: connects VCS (Git), CI/CD, testing, and release workflows

🧰 Agile Development Tools (Two Pillars)

1) 🧑‍💻 Salesforce DX (for dev lifecycle)

Key features

  • Salesforce CLI: create/manage orgs, run tests, deploy, data ops
  • Scratch Orgs: ephemeral, configurable, ideal for CI & parallel work
  • Source-Driven Dev: VCS-first changes, better merge & audit
  • Dev Hub: manage scratch orgs at scale

Advantages

  • Faster iteration via scratch org spin-up
  • Fewer conflicts → VCS-first collaboration
  • Strong CI/CD fit → quality + speed
  • Configurable + disposable envs → adapt quickly

2) 📋 Agile PM Tools (Jira/Agile Accelerator/Asana)

Core features

  • Backlog management (prioritize stories/bugs)
  • Sprint planning & capacity
  • Kanban/Scrum boards for flow + bottlenecks
  • Collaboration (comments, mentions, doc share)
  • Reporting (burndown, velocity, forecasts)
  • Integrations (Git, CI, test automation)

Benefits

  • Transparency for teams & stakeholders
  • Productivity via automation & focus on high-value work
  • Quality from continuous feedback
  • Consolidation of artifacts; integration with testing/CI
  • Scale from small squads to enterprise programs

🧭 Scenario → Recommended Agile Tooling

Integrate PM tool ↔️ CI/Test to surface build & test status on user stories.

🏛️ Org Strategy (Single.Org vs Multi.Org)

💡 Core Idea

Org strategy = how Salesforce is structured to maximize business value:
Architecture + Business + Technical considerations determine single vs multi.

🔀 Decision Drivers

  • Architectural: operating model, integration strategy
  • Business: funding, control, LOB count, cost of many orgs, need for Customer 360
  • Technical: change control, security/compliance/PII, Chatter scope, admin model, limits

🧩 Enterprise Architecture Operating Models

ModelIntegrationStandardizationTypical StrategyNotes
DiversificationLowLowMulti.orgIndependent units; consolidation is hard
ReplicationLowHighMulti.org (+managed package from hub)Same processes, local autonomy
CoordinationHighLowFew orgs (ideally single)Shared data; integration heavy
UnificationHighHighSingle.orgOne business, global standards

Integration Patterns

Hub & Spoke (master data share) • ESB (decoupled) • Salesforce Connect (reference master data) • Managed Packages (push shared functionality)

💼 Business & Technical Highlights

  • Customer 360 / Global Case Management → bias Single.org
  • Compliance/PII isolation → may require separate orgs
  • Multiple LOBs ≠ automatic multi.org: try COE, delegated admin, tiered data, license tax funding
  • Complexity in single.org: naming, sharing model, Apex architecture, data architecture maturity
  • Governance: COE, RACI, review boards, tiered admin
  • Org limits: sometimes new org or increase limits with Salesforce

Scenarios

🏗️ Sandbox Strategy

🧪 Sandbox Types & Uses

TypeTypical UsesData
DeveloperDev, unit tests, hotfix devMetadata only
Developer ProDev + larger datasets, QA, integrationMetadata + more storage
Partial CopyUAT, integration, trainingMetadata + sample data (template)
FullPerformance, load, staging/UATFull data + metadata

🔁 Refresh Intervals & Storage

SandboxRefreshStorage
Developer1 day200 MB data + 200 MB files
Developer Pro1 day1 GB data + 1 GB files
Partial Copy5 days5 GB data; files = prod
Full29 daysSame as prod

Can’t refresh?

Check license entitlements. Delete unused Fulls to match purchases and restore refresh ability.

Scenarios

Refresh Guidance

Refresh when source config drifts; Dev/Dev Pro daily, Partial every 5 days, Full every 29 days.

🚚 Deployment Strategy

🧱 Deployment Components

  • Metadata components (objects, fields, Apex, LWC, flows, etc.)
  • Data components (reference/seed data)
  • Governance & Change Mgmt (RACI, approvals, audit trail)
  • Test plans & scripts (unit/func/integration/regression/load/UI)
  • Rollback strategy (backups, package reverts, destructiveChanges)

🔧 Deployment Tools (When to Use What)

ToolBest ForNotes
Salesforce DXSource-driven dev, scratch orgs, packagingWorks great with CI/CD
Salesforce CLIScriptable deploys/tests/data opsAutomate everything
Metadata APIBulk metadata movesPull/push across envs
Ant Migration ToolRepeatable scripted deploysGood for pipelines
Change SetsSimple config between related orgsEasy UI; org locks during validate/deploy; one Flow version
Packages (Unlocked)Modularize + version deploymentsImmutable versions; rollback-friendly
Automated TestingRegression safety at speedSelenium etc.
CI/CD (Jenkins, GitHub Actions, Copado, Flosum)Pipeline automationPromote via PR/merge events

Faster, safer deploys

  • Use recent validations + Quick Deploy

  • RunSpecifiedTests for targeted coverage

  • Pre-create backup sandbox or capture metadata snapshot for rollback

Scenarios

🧪 Quick Decision Guides

📚 Flashcard Callouts (Collapse for Study)

📊 Handy Tables

Sandbox Use Matrix

Need ↓ / Type →DevDev ProPartialFull
Unit Dev/Test✅✅◻️◻️
Integration◻️✅✅✅
UAT◻️◻️✅✅
Performance/Load◻️◻️◻️✅
Training (sample data)◻️◻️✅◻️
Staging◻️◻️◻️✅

Tool Comparison (Speed vs Control)

AxisChange SetsDX/CLIAnt/APIUnlocked PkgsCI/CD
Setup EffortLowMedMedMed–HighHigh
RepeatabilityLowHighHighHighHigh
Governance FitLow–MedHighHighHighHigh
RollbackLowMedMedHighHigh (w/ packages)
Best ForSimple configScripted devLarge movesModular releasesAutomation at scale

🧠 Final Takeaways

  • Pair Salesforce DX with an Agile PM tool for speed + quality + transparency.
  • Choose org strategy by integration/standardization needs and compliance.
  • Build a sandbox ladder that mirrors your release pipeline.
  • Automate with DX/CLI + CI/CD, keep tests + rollback first-class.

📈 Flow Charts

1) 🚀 Agile Development Workflow (DX + PM Tools)

graph LR
  A[Product Backlog] --> B[Sprint Planning]
  B --> C[Create Work Items]
  C --> D[Dev Task Board]
  D --> E[Scratch Org DX]
  E --> F[Source in Git]
  F --> G[CI Build and Test]
  G --> H[Deploy to Integration Sandbox]
  H --> I[QA or UAT]
  I --> J[Deploy to Production]
  J --> K[Monitor and Feedback]
  K --> A[Product Backlog]

2) Org Strategy Decision (Single vs Multi)

graph TD
  S[Start Org Strategy] --> Q1{High Integration Across Units}
  Q1 -->|Yes| Q2{High Process Standardization}
  Q1 -->|No| Q3{Strict Compliance Or Data Isolation}
  Q2 -->|Yes| SO[Recommend Single Org]
  Q2 -->|No| FO[Few Orgs Preferred]
  Q3 -->|Yes| MOI[Recommend Multi Org]
  Q3 -->|No| Q4{Independent But Similar Units}
  Q4 -->|Yes| MOR[Multi Org With Managed Packages]
  Q4 -->|No| MOD[Multi Org Independent Units]
  SO --> GOV[Strong Governance And Shared Data]
  FO --> GOV
  MOI --> HUB[Use Hub And Spoke Or Reporting Hub]
  MOR --> HUB
  MOD --> HUB

3) Sandbox Strategy Picker

graph TD
  S[Need An Environment] --> D{Dev Or Unit Test}
  D -->|Yes| DEV[Developer Or Dev Pro]
  D -->|No| I{Integration Or UAT}
  I -->|Subset Data| PC[Partial Copy]
  I -->|Full Data| FULL[Full Sandbox]
  PC --> T[Training With Weekly Refresh]
  FULL --> ST[Staging Or Load Testing]
  DEV --> HF{Hotfix Needed}
  HF -->|Yes| PATH[Dev To Full To Prod Then Merge Back]
  HF -->|No| DEV

4) Deployment Pipeline With Rollback

graph TD
  A[Commit To Git] --> B[CI Lint And Unit Tests]
  B --> C{Tests Pass}
  C -->|Yes| D[Build Package]
  C -->|No| A
  D --> E[Deploy To Integration]
  E --> F[Automated Tests]
  F --> G{OK For UAT}
  G -->|Yes| H[Deploy To UAT]
  G -->|No| A
  H --> I{UAT Approved}
  I -->|Yes| J[Deploy To Production]
  I -->|No| A
  J --> K[Post Deploy Monitor]
  K --> L{Issues Found}
  L -->|Yes| R[Rollback Using Backup Or Destructive Changes]
  L -->|No| N[Tag Release And Close]

5) Hotfix Fast Path

graph LR
  P[Production Incident] --> T[Triaged And Scoped]
  T --> D[Fix In Dev Sandbox]
  D --> U[Unit Tests And Checks]
  U --> V{Tests Pass}
  V -->|Yes| F[Quick UAT In Full Sandbox]
  V -->|No| D
  F --> A{Approved}
  A -->|Yes| DEP[Deploy To Production]
  A -->|No| D
  DEP --> M[Monitor And Postmortem]
  M --> B[Merge Hotfix Back To Main]

6) Hub And Spoke For Customer 360

graph TD
  A1[LOB A Org] --> HUB[Customer 360 Hub]
  A2[LOB B Org] --> HUB
  A3[Region APAC Org] --> HUB
  A4[Region EMEA Org] --> HUB
  HUB --> REP[Reporting Or BI]

📚 Flashcards

📌 Agile Tools

🏛️ Org Strategy

🧪 Sandbox Strategy

🚚 Deployment Strategy

Recent Notes

Graph View