Salesforce Packaging Options – A Comprehensive Guide for Enterprise Development

Salesforce provides multiple packaging mechanisms for distributing metadata and code across organizations. Choosing the right package type depends on your distribution goals, intellectual property requirements, and organizational structure. This analysis examines five primary package types and provides recommendations for enterprise code distribution.

Package Types Overview

1. Unmanaged Packages

Unmanaged packages are collections of application components that can be distributed and installed in other Salesforce orgs. Once installed, the components become editable by administrators and developers in the target org.

Characteristics

Pros

• Simple to create and distribute
• Recipients can fully customize the code
• No ongoing maintenance required from publisher
• No namespace prefix added to components
• Good for sharing templates and starter code

Cons

• No version control or upgrade capability
• No intellectual property protection
• Changes must be manually tracked
• Cannot push updates to installed orgs
• No way to recall or enforce standards

Best Use Cases

• Distributing open-source projects to developers
• One-time deployment of applications requiring customization
• Sharing code templates or starter kits
• Internal proof-of-concept transfers

2. Managed Packages (First-Generation – 1GP)

First-generation managed packages are the traditional method for ISVs to distribute applications on AppExchange. They provide intellectual property protection and version management.

Characteristics

Pros

• Full intellectual property protection
• Automatic code obfuscation for Apex
• Version management and upgrade paths
• License management capabilities
• AppExchange distribution ready
• Push upgrades to subscriber orgs

Cons

• Org-based development model limits collaboration
• Each package requires unique namespace, causing proliferation of global Apex
• Managing hundreds of packaging orgs becomes complex
• Difficult to adopt modern CI/CD practices
• Monolithic architecture encouraged
• Limited code sharing between packages

When to Use

• Legacy AppExchange applications
• When specific metadata types only support 1GP
• When dependent packages must be 1GP

3. Second-Generation Managed Packages (2GP)

Second-generation managed packages represent the modern approach to ISV development, combining intellectual property protection with source-driven development practices.

Characteristics

Key Advantages Over 1GP

Pros

• Source-driven development with version control as source of truth
• Multiple packages can share a single namespace
• Single Dev Hub org manages all packages
• Full CI/CD integration capability
• Modular package architecture
• @namespaceAccessible annotation for code sharing
• Package Migrations feature for 1GP conversion

Cons

• 75% code coverage required for release
• Learning curve for source-driven development
• Requires Dev Hub org setup
• Some metadata types may not be supported yet

Namespace Sharing Example

With 2GP, you can share Apex code across packages using the @namespaceAccessible annotation:

@namespaceAccessible
public class SharedUtility {
    @namespaceAccessible
    public static String formatCurrency(Decimal amount) {
        return '$' + amount.format();
    }
}

4. Unlocked Packages

Unlocked packages are designed for enterprise customers and internal development teams. They provide the benefits of modular development without the restrictions of managed packages.

Characteristics

Pros

• Ideal for internal business applications
• Modular development with dependency management
• Version control integration
• Repeatable, scriptable deployments
• Administrators can still modify metadata after installation
• Supports modern DevOps practices
• Team-based ownership of packages

Cons

• No intellectual property protection
• Not suitable for AppExchange distribution
• 75% code coverage for released versions
• Package version creation has daily limits
• ~8 minute wait for package version creation

Modular Architecture Benefits

5. Org-Dependent Unlocked Packages

Org-dependent unlocked packages are a specialized variant designed for complex, legacy Salesforce orgs that have accumulated tightly coupled metadata over years.

Characteristics

Pros

• Perfect for legacy orgs with complex dependencies
• Incremental path to modular architecture
• No need to package all dependencies upfront
• Reduces refactoring effort for existing orgs

Cons

• Can only be installed in specific org configurations
• Less portable than standard unlocked packages
• May perpetuate technical debt if overused

Comparison Matrix

*For released versions only

Decision Framework: Which Package Type to Use?

Quick Reference Guide

Best Practices for Distributing Common Code in an Organization

Strategy 1: Modular Unlocked Package Architecture

For most enterprises, the recommended approach is a layered unlocked package architecture:

Strategy 2: Team-Based Package Ownership

Assign teams to own specific packages for better accountability:

Strategy 3: Namespace Considerations

Without Namespace: – Simpler for single-team organizations – Easier metadata references – No prefix on API names

With Namespace: – Recommended for multi-team environments – Clear ownership boundaries – Prevents naming conflicts – Required if you might distribute externally later

Strategy 4: Version Control Structure

salesforce-packages/
├── sfdx-project.json
├── packages/
│   ├── core-utilities/
│   │   ├── main/default/
│   │   │   ├── classes/
│   │   │   ├── triggers/
│   │   │   └── objects/
│   │   └── test/default/
│   ├── data-model/
│   ├── sales-app/
│   └── service-app/
├── scripts/
│   ├── create-scratch-org.sh
│   └── deploy-packages.sh
└── .github/
    └── workflows/
        └── ci-cd.yml

Implementation Roadmap

Want to master Salesforce DX and packaging? Check out my Salesforce DX course on Udemy for hands-on training covering scratch orgs, unlocked packages, CI/CD pipelines, and more.

Phase 1: Assessment

1. Analyze existing metadata – Catalog all components
2. Identify package boundaries – Group related functionality

Phase 2: Setup

1. Enable Dev Hub in your production org
2. Define namespace (if using)
3. Create package structure in sfdx-project.json
4. Establish CI/CD pipelines

Phase 3: Development

1. Start with core package containing shared utilities
2. Add dependent packages incrementally
3. Implement automated testing
4. Validate in scratch orgs

Phase 4: Deployment

1. Deploy to sandbox for UAT
2. Promote packages to released status
3. Install in production
4. Monitor and iterate

Package Dependencies and Architecture

Dependency Declaration

In sfdx-project.json:

{
  "packageDirectories": [
    {
      "path": "packages/core-utilities",
      "package": "Core Utilities",
      "versionName": "Winter '26",
      "versionNumber": "1.0.0.NEXT"
    },
    {
      "path": "packages/sales-app",
      "package": "Sales App",
      "versionName": "Winter '26",
      "versionNumber": "1.0.0.NEXT",
      "dependencies": [
        {
          "package": "Core Utilities",
          "versionNumber": "1.0.0.LATEST"
        }
      ]
    }
  ],
  "namespace": "mycompany"
}

Dependency Rules

Avoiding Circular Dependencies

• Design clear hierarchical layers
• Core/utility packages at the bottom
• Application packages at the top
• Use interfaces to decouple when needed

Common Pitfalls and Solutions

Pitfall 1: Monolithic Package Syndrome

Problem: Creating one large package with all metadata

Solution: Break into smaller, focused packages with clear responsibilities

Pitfall 2: Ignoring Code Coverage

Problem: Failing to maintain 75% code coverage

Solution: Include tests in packages, run coverage on every build

Pitfall 3: Over-Engineering Dependencies

Problem: Creating too many small packages with complex dependency chains

Solution: Balance modularity with practical maintainability

Pitfall 4: No Namespace Strategy

Problem: Conflicts when multiple teams develop independently

Solution: Use namespace for multi-team environments

Pitfall 5: Skipping Scratch Org Testing

Problem: Packages work in sandboxes but fail in fresh orgs

Solution: Always validate packages in scratch orgs first

Recommendations

For Enterprise Internal Development

Primary Choice: Unlocked Packages

1. Start with a core utilities package containing shared code
2. Create functional packages for major business areas
3. Use org-dependent packages for legacy transitions
4. Implement CI/CD with automated testing
5. Consider namespace for large multi-team organizations

For ISVs and AppExchange Partners

Primary Choice: Managed 2GP

1. Adopt source-driven development from the start
2. Use namespace sharing for modular products
3. Leverage @namespaceAccessible for code sharing
4. Plan for Package Migrations if converting from 1GP
5. Maintain 75% code coverage continuously

For One-Time Code Sharing

Primary Choice: Unmanaged Packages

1. Use for templates and starter kits
2. Document clearly what customization is expected
3. Consider providing as open-source on GitHub alongside

Key Findings

• Unlocked Packages are the recommended choice for internal enterprise development
• Managed 2GP packages are ideal for AppExchange distribution with modern DevOps practices
• Unmanaged Packages are suitable only for one-time code transfers
• Modular architecture with package dependencies enables scalable enterprise development

Have questions about Salesforce packaging options? Drop a comment below!