Salesforce Packaging - Distributing & Managing Customizations

1. Introduction to Salesforce Packaging

In Salesforce development, once you've built custom functionalities like Apex code, Lightning Web Components, custom objects, or flows, you often need to move these customizations between different Salesforce environments (e.g., from a Sandbox to Production) or distribute them to other Salesforce organizations. This is where Salesforce Packaging comes in.

Salesforce packaging allows you to bundle your metadata (your customizations) into deployable units. These packages can then be installed into other Salesforce organizations, streamlining the process of distribution, deployment, and version management of your applications or components.

Why is Packaging Important?

• Distribution: Easily share your custom solutions with other Salesforce organizations.
• Version Control: Manage different versions of your application or components.
• Deployment: Simplify the process of moving changes across environments or to customers.
• Intellectual Property Protection: For commercial applications, protect your source code.
• Modularity: Break down large implementations into smaller, manageable, and reusable units.

This module will explain the different types of Salesforce packages – Unmanaged, Managed (1st Generation and 2nd Generation), and Unlocked Packages – highlighting their characteristics, use cases, and how to create them.

2. Unmanaged Packages

Unmanaged packages are the simplest type of package and are primarily used for distributing open-source projects, templates, or small, self-contained applications. Think of them as a "copy-paste" mechanism for Salesforce metadata.

• Description: An unmanaged package bundles a collection of metadata components. Once installed in a target organization, these components become fully editable and belong entirely to the installing organization. There's no ongoing connection or upgrade path from the original developer.
• Key Characteristics:
  • Editable: All components (Apex, LWC, custom objects, etc.) are fully customizable by the installing organization.
  • No Upgrade Path: There's no built-in mechanism for the original developer to push updates or new versions to installed unmanaged packages. If you want to update, you typically have to manually re-deploy the changes or install a new version, which might overwrite local changes.
  • No Intellectual Property Protection: The source code of Apex classes, Visualforce pages, etc., is visible and accessible after installation.
  • No Namespace: Components within an unmanaged package do not have a unique namespace prefix. This means there's a higher risk of naming conflicts if the installing org already has components with the same name.
  • Deletion: Uninstalling an unmanaged package removes the package container, but the installed components remain in the target org. You have to manually delete the components.
• Use Cases:
  • Sharing sample code or templates with other developers.
  • Distributing open-source projects or utilities.
  • Providing a starting point for a customer's implementation that they will then customize heavily.
  • Migrating components between non-related developer orgs (though Change Sets or SFDX are often preferred for internal orgs).
• How to Create (Declarative - via Salesforce UI):

  This is the easiest way for admins or developers to create a quick unmanaged package.

  1. Log in to your Salesforce Developer Edition or Sandbox org where your customizations reside.
  2. Go to Setup.
  3. In the Quick Find box, type Package Manager and select Package Manager (or Packages).
  4. Click the New button under "Unmanaged Packages".
  5. Provide a Package Name (e.g., "MyUtilityComponents") and optionally a description. Click Save.
  6. On the Package Detail page, click Add Components.
  7. Select the Component Type (e.g., Apex Class, Custom Object, Lightning Web Component) and then select the specific components you want to include. Click Add To Package. Repeat for all components.
  8. Once all components are added, click the Upload button.
  9. Review the package details and click Upload again. Salesforce will provide an installation URL that you can share.
• How to Create (SFDX CLI - Integration with UI):

  While the SFDX CLI does not have a direct command to *create* an unmanaged package container, it is instrumental in preparing your source code for unmanaged package creation via the Salesforce UI. You manage your source code in an SFDX project, push it to a development org (sandbox or scratch org), and then use the declarative UI to create the unmanaged package from that org. Alternatively, the Ant Migration Tool can be used with a package.xml to deploy components, which effectively acts as an unmanaged deployment.

  # SFDX is primarily used for source-driven development and 2GP.
  # For unmanaged packages, the typical SFDX workflow involves:
  # 1. Developing your customizations in a scratch org or sandbox.
  # 2. Pulling the source to your local SFDX project:
  #    sf project retrieve start -o myDevOrg
  # 3. Then, you use the Salesforce UI (Package Manager) in that same org to create the unmanaged package,
  #    selecting the components that are now present in the org from your SFDX project.
  # Alternatively, for programmatic unmanaged deployments, you could use the Ant Migration Tool
  # with a package.xml to deploy source to another org.
  

3. Managed Packages (1st Generation & 2nd Generation)

Managed packages are the cornerstone for Salesforce ISVs (Independent Software Vendors) to distribute and sell their applications on the AppExchange. They offer crucial features like intellectual property protection, upgrade capabilities, and a unique namespace.

• Key Characteristics (Common to both 1GP and 2GP Managed):
  • Protected Components: The source code of Apex classes, Visualforce pages, and other intellectual property is hidden from the installing organization. Components are generally not editable after installation.
  • Upgrade Path: The package developer can push upgrades to installed managed packages, allowing customers to receive new features and bug fixes.
  • Unique Namespace: All components within a managed package have a unique namespace prefix (e.g., mycompany__MyComponent__c). This prevents naming conflicts with components in the installing organization or other managed packages.
  • AppExchange Distribution: Required for listing applications on the Salesforce AppExchange.
  • Version Control: Strong versioning capabilities, allowing for clear release management.

a. 1st Generation Managed Packages (1GP):

• Description: This is the traditional way to create managed packages, typically developed in a single Developer Edition org (often called a "packaging org"). It's an org-centric development model.
• Development Model: Org-based development. You develop your metadata directly in a special Developer Edition organization, which then becomes your packaging org. All components for the package must reside in this single org.
• Limitations:
  • Can be difficult to manage for large, modular applications as all components are in one monolithic package.
  • Limited direct integration with modern source control practices for package definition.
  • No support for scratch orgs.
  • Dependencies between packages are harder to manage.
• Creation (High-Level - via Salesforce UI in a Packaging Org):

  1GP creation is done primarily through the Salesforce UI in a special Developer Edition org that you designate as your packaging org.

  1. Request a special Developer Edition org for packaging (if you don't have one).
  2. Develop all your application's metadata directly in this packaging org.
  3. In Setup, go to Package Manager (or Packages).
  4. Click New under "Managed Packages".
  5. Provide a Package Name, select a Namespace Prefix (this is crucial and unique), and fill in other details. Click Save.
  6. Add all your developed components to this package.
  7. Click Upload to create a new version of your managed package.