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 Type | Best For | Upgrade Path | Customization in Subscriber Org | Namespace / IP Protection | Typical Use |
---|---|---|---|---|---|
Managed | ISVs distributing/selling apps | Yes (versioning, push upgrades) | Limited (per component rules) | Yes (namespace, licensing, security review) | AppExchange apps |
Unmanaged | One-time handoff / open source | No (no upgrades) | Full (subscriber can edit components) | No | Code samples, accelerators |
Unlocked | Modular, source-driven internal apps | Yes (versioned, iterative) | Org can extend; can be namespace-free or namespaced | Optional | Enterprise 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
Sandbox | Best For | Notes |
---|---|---|
Developer | Isolated dev | Small storage; fast refresh |
Developer Pro | Dev + light QA/integration | More storage |
Partial Copy | UAT, integration, training | Subset of prod data |
Full | Staging, UAT, performance/load | Full 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
Type | Cadence | Examples | Effort / Impact |
---|---|---|---|
Immediate | Daily/as-needed | Reports, dashboards, data loads | Low effort, minimal training |
Minor | Weekly/Monthly | New fields, layouts, flows, small triggers | Medium effort; short training |
Major | Quarterly | Apps, integrations, migrations | High effort; >1 week config/integration; formal training |
Hotfix: Fast path for urgent prod issues; UAT optional depending on risk; ensure downstream sync.
π§ Governance & Roles
Group | Responsibilities |
---|---|
Steering Committee | Strategy, 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
What are the 3 package types in Salesforce?
Managed β for distributing ISV apps on AppExchange
Unmanaged β for one-time editable delivery or open-source projects
Unlocked β for modular, source-driven enterprise development
When to use Managed packages?
β For AppExchange, with IP protection, licensing, versioning, and upgrade paths
When to use Unmanaged packages?
βοΈ For editable source code you give away once, no version upgrades (not for sandbox β prod migration)
When to use Unlocked packages?
π§© For modular development within your org(s) β source-driven, versioned, and flexible for regional customizations
What is
@namespaceAccessible
used for?To let Apex methods be shared only across 2GP packages within the same namespace
βοΈ Managed Packages (2GP)
Key benefits of Managed 2GP?
Source-driven development
API/CLI-first, CI-ready
Namespace sharing & code reuse
Declarative dependencies
Flexible versioning & patching
How are managed package versions controlled?
π¦ Each version is immutable, uses semantic versioning, and can be promoted and upgraded
How to let Apex in a not-yet-certified managed pkg deploy metadata?
β Enable Deploy Metadata from Non-Certified Package Versions via Apex in Setup β Apex Settings
π§© Unmanaged & Unlocked Packages
Can subscribers edit unmanaged package components?
β Yes β they become org-owned and are fully editable
Can publishers upgrade unmanaged packages?
β No β they cannot push changes after install
Why use unlocked packages?
Modular app development
Source of truth in VCS
Multi-level dependency support
Optional namespace
Can unlocked packages be upgraded?
β Yes β install new versions iteratively like managed packages
π§ͺ Sandbox Strategy
What sandbox type for individual dev streams?
π» Developer / Developer Pro
What sandbox type for UAT or integration testing?
π§ͺ Partial Copy
What sandbox type for staging or performance testing?
ποΈ Full (complete replica of production)
How to handle training with real data safely?
Use Partial or Full sandbox with Salesforce Data Mask to anonymize sensitive data
What is a sandbox preview?
π§ͺ Lets you test your org on the next Salesforce release before production is upgraded
β‘ Hotfixes
What is a hotfix?
β‘ A quick, urgent fix for a production issue
Hotfix path steps?
Dev in Developer β Test in Partial/Full β Deploy to Prod β Sync downstream sandboxes
π Release Management Basics
What are the 3 main release types?
Immediate: daily, low risk, e.g. reports
Minor: weekly/monthly, small features, e.g. flows, fields
Major: quarterly, big changes, e.g. new apps, integrations
When to avoid major releases?
β Near peak business seasons to avoid disruption
Who owns release governance?
Steering Committee: strategy, priorities, resource decisions
Center of Excellence (COE): standards, process, oversight
Key pillars of release management?
π Deployment size/cadence, project evaluation, environment strategy, training/comms, ongoing support
Typical release lifecycle steps?
π Plan β Gather Requirements β Design β Build β Test β Release β Maintain
π§ͺ Extra Scenarios
How to support multi-region teams who need to customize global code?
Use unlocked base package + regional unlocked extensions; manage with source control & dependencies
How to safely release a major project near an upcoming Salesforce release?
Refresh non-preview sandboxes before cut-off to move to preview, then test features on the new release
How to handle urgent bug fixes?
Use hotfix path β build in Dev β test in Full β deploy β sync