Package an AppExchange App
After completing this unit, you’ll be able to:
- List the key features of a namespace.
- Describe the benefits of using Managed - Released packages for AppExchange partners.
- Describe the impact of installing a Managed - Beta package versus a Managed - Released package.
A package is a container for components, like a Java JAR file or a Ruby GEM, that you use to distribute your app to customers. It contains a set of metadata with a unique namespace. A package can contain something as small as an individual component or as large as a set of related apps.
The Salesforce platform, by its very nature, encourages an agile development model in which you test incrementally and adapt your design as you go. Managed - Beta packages support this test-and-modify approach.
A Managed - Released package is used for a live product. Your customers expect a stable app that evolves over time without breaking the business processes that they’ve built on top of it. A Managed - Released package helps to ensure that you don’t break customers’ customizations and provides protection for your intellectual property.
Managed - Released packages provide:
- Intellectual property protection for Apex
- Built-in versioning support for API accessible components
- Ability to branch and patch a previous version
- Ability to seamlessly push patches and major updates to subscribers
- Unique naming of all components to ensure conflict-free installs
- Ability to control subscriber access via licenses
Let’s look at the packaging and distribution lifecycle of your app.
- You publish version 1 of your app in a Managed - Released package.
- The customer installs the package.
- The customer customizes your app.
- You publish version 2 of your app in a Managed - Released package.
- The customer installs the new version of the package on top of the existing package.
We say a Managed - Released package is upgradeable because customers can install a new version over their existing version. Unmanaged packages, which are not generally used by partners, and Managed - Beta packages are not upgradeable.
The Salesforce platform is highly customizable, and your customers are likely to customize your app. They depend on a certain level of consistency in your app when you release a new version so that their customizations don’t break.
A Managed - Released package has built-in safeguards to minimize the impact of new versions. For example, you can’t remove Apex methods that have been made available to customers or objects. Check out the Components Available in Managed Packages section in the ISVforce Guide for more details.
We’re going to break our own rules here and set up a simple app in the same org where we create a package. You can create packages only in a Partner Developer Edition (PDE) or Developer Edition org. So use the PDE org we created in the last unit.
Let’s walk through the steps of creating one of the world’s simplest apps to do some hands-on packaging. We are going to create a one-page app that displays a custom object.
- Go to the Setup menu.
- On the Lightning Platform home page, click Add App.
- Fill out the App Quick Start page as follows.
Field Value App Trail Tracker Label Trail Plural Label Trails
- Click Create.
- Click Go To My App
That’s it. Let’s try out the app.
- Click New.
- For the Trail name, enter AppExchange Partner Basics.
- Click Save.
You’ve created a record with your app. Easy-peasy.
For all AppExchange apps and some OEM Embedded apps, customers install your app in an existing org with customizations. Consider the following scenario.
- A customer has created a custom object with the API name Vendor__c.
- Your app has a custom object with the API name Vendor__c.
Will installing your app overwrite your customer’s object? No, thank goodness. Namespaces rescue us from that fate.
To prevent conflicts, a managed package always has a namespace. A namespace is unique across Salesforce so that the installation of a managed package doesn’t conflict with customizations made by customers and other partners.
A development org can have only one namespace. You can create only one package using that namespace, but you can make updates to the package and release new versions.
When you create a namespace in an org, it is attached to every component within the org. If you create a package in that org, every component you add to the package comes with the namespace. The following custom object shows that (1) the org has the namespace TrailApp_Test1, and (2) the Trail object’s API name is TrailApp_Test1__Trail__c.
Because namespaces are unique, choose the namespace for your golden package org first. Your customers see the namespace that you use for the package you upload to the AppExchange. If your company name is AW Computing, you want a namespace like awc or awcomputing.
Do not use that namespace in your beta packaging org, because then it isn’t available for your golden package org.
Let’s create your namespace so that you can package up your app.
- From Setup, enter Package in the Quick Find box, then click Packages.
- In the Developer Settings section of the page, click Edit.
- To confirm that you want to set up a namespace, click Continue.
- Enter a value for Namespace Prefix. Remember, do not use a name you might want to use later.
- Click Check Availability. Repeat steps 4 and 5 until you find an available namespace.
- Click Review My Selections.
- Click Save.
What makes a Managed - Released package the best choice for selling and distributing your app also makes it a poor choice for testing. After you add certain components to a managed package, you can’t modify them. Let’s say in developing your app, you create four custom objects, Larry, Curly, Moe, and John. When you go to test your app, you decide John is unnecessary. Sorry! If the object John is in your Managed - Released package, you can’t remove it.
To get around this issue, we provide Managed - Beta packages. The components of a beta package are editable in your package org until a Managed - Released package is created.
Go ahead and follow these steps to create your Managed - Beta package.
- If you aren’t on the packages page, from Setup, enter Package in the Quick Find box, then click Packages.
- In the Packages section, click New.
- For Package Name, enter Trail App.
- Select the Managed checkbox to enable that option. When prompted, click OK.
- Click Save.
- In the Components subtab, click Add.
- Choose the Trail Tracker app, and click Add to Package. Notice that several dependent components were added to the package.
- Click Back to Package List.
Notice that by default a Managed - Beta package was created, just what we wanted.
Beta versions aren’t considered major releases, so the package version number doesn’t change.
When you are ready to install your package in another org, you upload it.
- Click your package name from the list of packages.
- Click Upload.
- Fill out the Package Details section as follows.
Field Value Version Name Trail App Test 1 Description The beta package for the simple app I created working through the Build Apps as an AppExchange Partner trail.
- Click Upload. If the upload is successful, you get a message with an installation URL.
- Copy the installation URL to use in installing your package.
- Log out of your org.
- Paste the installation URL in your browser.
- On the login page that appears, enter the credentials for the Trailhead Test org that you created in unit 2.
- On the page that appears, click Install.
- Click Done.
- Verify that your app has been installed by choosing it from the app menu.
You now know the basics about packages.
- You must create packages in a Partner Developer Edition or Developer Edition org.
- To create the package, choose a unique namespace.
- Don’t use up your good namespace on test orgs, or you’ll be sorry.
- Use Managed - Beta packages during the testing cycle, because it’s easy to modify their contents.
- Use a Managed - Released package only for final testing.
Congratulations, you have all the skills to use Managed - Beta packages in your development cycle. The challenge gives you a bit more practice.