Releasing consists of 13% of total score in Salesforce Platform Lifecycle and Deployment Architect Exam. The topic covers package types, strategy for releasing, and release management 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.

πŸš€ Releasing in Salesforce

Goal: Choose the right package type (managed / unmanaged / unlocked), and build a release plan that aligns sandboxes, staging, training, and hotfixes.


πŸ“¦ Package Types at a Glance

Package TypeBest ForUpgrade PathCustomization in Subscriber OrgNamespace / IP ProtectionTypical Use
ManagedISVs distributing/selling appsYes (versioning, push upgrades)Limited (per component rules)Yes (namespace, licensing, security review)AppExchange apps
UnmanagedOne-time handoff / open sourceNo (no upgrades)Full (subscriber can edit components)NoCode samples, accelerators
UnlockedModular, source-driven internal appsYes (versioned, iterative)Org can extend; can be namespace-free or namespacedOptionalEnterprise modularization, extensions

Quick picker

  • Want upgrades + IP protection for customers? β†’ Managed

  • One-time drop of editable source? β†’ Unmanaged

  • Modular, iterative releases across orgs/teams? β†’ Unlocked


🧰 Managed Packages (esp. 2GP) β€” Key Points

  • Why: Distribute, license, monetize; do push upgrades; pass security review to list on AppExchange.
  • 2GP Advantages: Source-driven, API/CLI-first, flexible versioning, namespace sharing, declarative dependencies, simplified patching.
  • Lifecycle: Every change β†’ new immutable version (semantic versioning).
  • Namespace: Same namespace can span multiple 2GPs; share code with @namespaceAccessible.
  • Tooling: Dev Hub, SFDX project, sfdx-project.json, Salesforce CLI, source control & CI.
  • Note: During pre-cert testing, enable β€œDeploy Metadata from Non-Certified Package Versions via Apex” if Apex must manipulate metadata.

🧰 Unmanaged Packages β€” Key Points

  • Why: Share editable metadata (one-time distributions, community/open source).
  • No upgrades: Publisher cannot update/patch after install.
  • Components: Explicit + implicit (dependencies) added to the package.
  • Conflicts: Some assets auto-rename (Reports/Dashboards); others block install on conflicts.
  • Cautions: Not for sandboxβ†’prod migration; ensure the uploading org still exists.
  • Can convert to managed after registering a namespace.

🧰 Unlocked Packages β€” Key Points

  • Why: Modularize enterprise metadata; source of truth = VCS; great for multi-team, multi-region work.
  • Dependencies: Support multi-level dependency graphs (managed + unlocked).
  • Versioning: Each version immutable; upgrade by installing newer versions.
  • Namespace: Optional (namespaced for isolation; or namespace-free to blend with org).
  • Requirements: Dev Hub, 2GP enabled, SFDX/CLI, DX project.

🧭 Which Package When? (Decision nudges)

Choose Managed if…

  • You need AppExchange listing, licensing, IP protection, and upgrade paths.

Choose Unmanaged if…

  • You want recipients to edit the code and no upgrade is required.

Choose Unlocked if…

  • You want modular, source-driven, iterative releases inside/among orgs, with dependency management.

πŸ§ͺ Scenario Callouts (Packages)

  • Pre-cert managed package fails Apex metadata ops in sandbox
    β†’ Enable Deploy Metadata from Non-Certified Package Versions via Apex; review scanner findings and mark false positives with justification if appropriate.
  • Two teams, two managed 2GPs, share only some methods
    β†’ Use same namespace; expose only needed methods with @namespaceAccessible.
  • New partner building a managed package; want to quickly add their app to main org
    β†’ Use Developer/Partner Dev Edition for managed package dev; for the quick add, ship an Unmanaged package into main org.
  • Global code with regional customizations
    β†’ Use Unlocked base + unlocked extensions per region; manage via source control, versioning, and dependencies.
  • Partners install app, must stay updated, and can extend via Flow/Triggers
    β†’ Managed package with upgrades; partners extend on top.
  • Move Apex classes from package A to package B (same namespace)
    β†’ Remove references in B, version B, then remove classes from A, version A.

πŸ§ͺ Sandbox Strategy for Releases

🧱 Sandbox Types & Uses

SandboxBest ForNotes
DeveloperIsolated devSmall storage; fast refresh
Developer ProDev + light QA/integrationMore storage
Partial CopyUAT, integration, trainingSubset of prod data
FullStaging, UAT, performance/loadFull replica; longest refresh window

Training & privacy

Use Partial/Full with Data Mask/anonymization for realistic yet compliant training data.


πŸ§ͺ Staging & Hotfixes

  • Staging: Validate in Full sandbox; schedule regular refresh to mirror prod.
  • Hotfix: Develop in Developer, test in Partial/Full, then deploy to prod; propagate downstream to keep environments in sync.

Release windows

Avoid major releases near peak business periods.


πŸ”­ Sandbox Preview Windows

  • Refresh non-preview sandboxes before the cut-off to move to preview (test upcoming release).
  • Refreshing after cut-off may keep/revert to non-preview.
  • Use the Sandbox Preview Guide to track and plan.

πŸ“… Release Management Strategy

🧩 Release Types

TypeCadenceExamplesEffort / Impact
ImmediateDaily/as-neededReports, dashboards, data loadsLow effort, minimal training
MinorWeekly/MonthlyNew fields, layouts, flows, small triggersMedium effort; short training
MajorQuarterlyApps, integrations, migrationsHigh effort; >1 week config/integration; formal training

Hotfix: Fast path for urgent prod issues; UAT optional depending on risk; ensure downstream sync.


🧠 Governance & Roles

GroupResponsibilities
Steering CommitteeStrategy, prioritization, resourcing, conflict resolution
Center of Excellence (COE)Standards, process, tooling, oversight, coordination with teams

πŸ” Process Pillars

  • Planning β†’ Requirements β†’ Design β†’ Build β†’ Test β†’ Release β†’ Maintain
  • Project evaluation: Submission β†’ COE review/prioritization β†’ Decision
  • Environment strategy: Right sandboxes, preview alignment, staging
  • Training & comms: Prepare users before go-live
  • Support: Monitor post-release and iterate

πŸ§ͺ Scenario Callouts (Releases & Sandboxes)

  • Major project + upcoming Salesforce release
    β†’ Refresh non-preview sandboxes before cut-off to move to preview; test against the new platform.
  • Urgent prod bugs + daily request for a report
    β†’ Use Full for urgent analysis/fixes; refresh after each prod hotfix. Daily report: build/test in Full, then deploy.
  • EU division cadence: majors every 4 weeks, minors weekly; SIT/UAT/training
    β†’ Minor UAT = Partial Copy; Major UAT & training = Full; separate Full for Staging.
  • Trigger + Flow on Opportunity (small scope)
    β†’ Treat as Minor release with training/change management.
  • Testing team found issues; deadline tight
    β†’ Fix in Developer, move to testing sandbox for verification, then deploy; do not fix directly in test and push to prod.

πŸ“ˆ Flow Charts

1) Choose package type

flowchart TD
    A[Packaging need] --> B[Managed]
    A --> C[Unmanaged]
    A --> D[Unlocked]
    B --> E[AppExchange distribution]
    B --> F[Licensing and upgrades]
    C --> G[One time editable source]
    C --> H[Open source sharing]
    D --> I[Modular internal releases]
    D --> J[Source driven development]

2) Managed 2GP development workflow

flowchart TD
    A[Create sfdx project] --> B[Enable dev hub]
    B --> C[Configure sfdx project json]
    C --> D[Develop features]
    D --> E[Create package]
    E --> F[Create package version]
    F --> G[Install in scratch org]
    G --> H[Run tests]
    H --> I[Promote version]
    I --> J[Release and upgrade]

3) Share code between managed packages with same namespace

flowchart TD
    A[Team B package] --> B[Public apex methods]
    B --> C[Add namespace accessible]
    C --> D[Team A package uses methods]
    D --> E[Other packages cannot use]

4) Unmanaged package creation and install

flowchart TD
    A[Create unmanaged package] --> B[Add components]
    B --> C[Upload package]
    C --> D[Receive install link]
    D --> E[Install in target org]
    E --> F[Edit components in target]

5) Unlocked packages for multi region model

flowchart TD
    A[Global base unlocked package] --> B[Region north extension]
    A --> C[Region south extension]
    A --> D[Region east extension]
    B --> E[Install to region org]
    C --> F[Install to region org]
    D --> G[Install to region org]

6) Move apex classes from package A to package B

flowchart TD
    A[Identify classes in package A] --> B[Remove references in package B]
    B --> C[Create new version of package B]
    C --> D[Remove classes from package A]
    D --> E[Create new version of package A]

7) Sandbox strategy across streams staging training hotfix

flowchart TD
    A[Multiple project streams] --> B[Developer sandboxes per team]
    B --> C[Merge to partial copy]
    C --> D[Merge to full for staging]
    D --> E[Deploy to production]
    A --> F[Training needs]
    F --> G[Use partial copy or full]
    A --> H[Hotfix request]
    H --> I[Develop in developer sandbox]
    I --> J[Test in partial or full]
    J --> E

8) Sandbox preview planning before release

flowchart TD
    A[Check upcoming release] --> B[Non preview sandboxes]
    B --> C[Refresh before cutoff]
    C --> D[Move to preview]
    B --> E[Refresh after cutoff]
    E --> F[Remain non preview]

9) Release type routing

flowchart TD
    A[New change request] --> B[Immediate]
    A --> C[Minor]
    A --> D[Major]
    B --> E[Build and validate quickly]
    C --> F[Build test uat schedule]
    D --> G[Plan design build sit uat training]
    G --> H[Staging in full sandbox]

10) Hotfix path

flowchart TD
    A[Urgent production issue] --> B[Create fix in developer sandbox]
    B --> C[Test in partial or full]
    C --> D[Deploy to production]
    D --> E[Sync downstream sandboxes]

πŸ“š Flashcards

πŸ“¦ Package Types


βš™οΈ Managed Packages (2GP)


🧩 Unmanaged & Unlocked Packages


πŸ§ͺ Sandbox Strategy


⚑ Hotfixes


πŸ“… Release Management Basics


πŸ§ͺ Extra Scenarios