Plan Your Move to Packages

Learning Objectives

After completing this unit, you’ll be able to:

Identify use cases where you can shift to a modular (package development) approach.
Identify a scenario that doesn't lend itself to package development.

Next Stop: Plan Your Transition to Packages

Now that you understand the value of the packaging development model, you're interested in moving forward with it. So how do you begin? Your next steps depend on the complexity and maturity of your production org and the associated development processes. Here are some suggestions to help you get started.

Why Now Is a Great Time to Adopt Packaging

It used to be that packages were for partners who wanted to build and distribute applications on AppExchange. But now there’s a new package sheriff in town for enterprises and customers: unlocked packages. If you’re a Salesforce customer, contractor, consultant, or systems integrator, unlocked packages are for you!

Unlocked packages provide a repeatable, scriptable, and trackable way to organize your work and manage change as you develop functionality.

And best of all, Salesforce CLI and DX projects make creating unlocked packages a snap. You can install unlocked packages in any Salesforce environment: scratch orgs, sandboxes, trial orgs, and production orgs.

If you want to know more, check out the Unlocked Packages for Customers module.

Assemble the Team

Perhaps you’ve heard the expression “No person is an island.” This same adage applies to teams. In many companies, your Salesforce production org has many stakeholders. As you get ready to embark on the journey of package development, one of the first tasks involves how to untangle your org. Before you begin, it’s important to include the right people.

Package Development Readiness provides strategies for assembling your team in preparation for moving to package development.

Look for Ways to Untangle the Org into Packages

Evaluate all aspects of your development process to look for possible ways to shift to the modular, package-based approach. Look for distinct applications in the production org that are separate from everything else. Do you have distinct teams that build and maintain these applications? If so, you can isolate those applications into their own packages. AppExchange has many great examples of standalone apps that follow this idea of isolating a set of source and metadata into a single package.

Sometimes, you don’t have a distinct application that you can split into a package, but you have distinct parts of your org that you’ve worked on over time. For instance, extensions to one of your core apps could be released as packages. You can isolate all of the extensions you make in customizing your company’s sales process into a single package. If you can isolate the metadata that is specific to these parts, you can use that to develop a package.

You can also look for teams who already, or would like to, build, and deliver separately from everyone else. Find teams who are looking for opportunities to be more agile and flexible. Or teams who want to separate their changes from the larger change management process in their production org. These teams can isolate their metadata and store them in their own package.

If you discover that breaking up the metadata in your org is very difficult, org-dependent unlocked packages may be right for you. Org-dependent unlocked packages are a variation of unlocked packages that allow you to create packages that depend on unpackaged metadata in the org where you plan to install the package (installation org).

Look Out for Shared Metadata

Along the way, ensure that you evaluate all potential packages for shared metadata components. You don’t want to inadvertently isolate shared metadata to a package owned by a specific team or application. If the metadata component is shared, we recommend that you organize those shared components into a single base package. In this way, you can ensure that all packages can reference the components in the shared base package. (Remember, metadata components can only live in one package at a time.)

Start Your Package Project

Once you’ve identified potential packages, you can use the Metadata API to retrieve the source related to your package. See App Development with Salesforce DX to walk through how you’d use Salesforce CLI and your testing org to create a package.xml that identifies the components for the package. Once you retrieve the source in metadata format, convert it to source format.

Then, create a VCS repository for each package. From there, continue the separation process by building packages specific to those applications.

Rome Wasn’t Built in a Day

If your organization has a mature or complex org, the shift to packages needs to occur over time. Your production org is your most prized possession, so plan your transition thoughtfully. Use the guidance in this unit to identify parts of your org that you can shift to packages. Shift one package at a time and continue to evaluate and improve your process.

Now that you know more about the package development model, it’s time to get your fingernails dirty by trying it out.

Looking for Help?

Discover More