Lions and tigers and packages, oh my! I often hear a lot of confusion around what Salesforce packages are, and how and when they should be used. The goal of this blog is to demystify packages and the act of packaging, and help answer some common questions about when to employ packages.
Package Defined:
A package is a collection of code and resources designed for easy transport between unrelated Salesforce orgs.
A few things about this definition – it’s defined a collection of code and resources. It’s not just code, packages often contain dashboards and other “button click admin” configuration items.
It’s designed for easy transport. Notice I did not say “download”. You don’t “download” things into your Salesforce org, since packages move things from cloud to cloud, you’re really transporting or installing them.
Finally, the term “unrelated” was used. Packages can move information from anywhere to anywhere provided the org types are compatible. For instance, you’d have difficulty moving a package that had workflow to a group edition org.
So why all these clarifications?
There are actually a handful of ways to move code and resources between Salesforce orgs, and the lines are sometimes blurry. This chart might help:
What the heck is a managed beta?
A managed beta is a special type of managed package. They are not upgradable but allow the managed package to be taken out of beta so that components can be removed after testing.
When do I really want a managed package?
After having built quite a few applications, generally a managed package is one of the last steps before final testing and security review. Up until that point, work with unmanaged or managed beta. The major challenge is that things change throughout testing. Once you create a managed package, you’re committed to it. Forever.
And what about change sets again?
Change sets are like “mini unmanaged packages”. They bundle up a series of functions and allow an administrator to move them between two related orgs. The major caveat here is that related orgs are generally sandbox, staging, production – owned by one company. Work great if you’re an administrator maintaining a company’s Salesforce instance. Not so great if you’re trying to build an application for public distribution.
Why would I use “a bunch of code” to move between orgs?
Creating an application that is manually moved via eclipse has some advantages for developers, namely that it’s flexible. Often in the formative/testing phase of an application build, it helps with troubleshooting and test coverage writing to be able to move components individually to find errors.
What’s on the AppExchange?
Everything available on the AppExchange is either a managed or unmanaged package.
Can I install an unmanaged package and delete parts of it?
Yes you can. This is why unmanaged packages are great for creating toolkits. Toolkit being defined as a set of functions that you can cherry pick components that you like and remove ones that you don’t. One of my strategies is to load an unmanaged package to a sandbox, pick the components I want, and then change set them to production, so I don’t have to worry about maintaining another package in production.
Can I install a managed package and delete parts of it?
Nope.
If I install a package, and uninstall it, what happens to the stuff?
All package components are deleted/removed from the system. Any data that was stored on custom objects related to the package are stored for 21 days and can be backed up or used for a restore later on if needed.
How many packages can I install?
There is no set limit, although depending on the type of package, additional limits may apply (such as tab limits)
Wait, Limits?
Yes, Salesforce has limits on things like how many custom tabs and custom objects you can create. Managed packages are exempted from those limits.
How many packages should I install?
There is no inherent harm in installing packages. However, as a part of your general Salesforce management strategy, each package should be selected with care, have strategic value, and be properly maintained.
How do you test packages?
It’s always recommended to load packages into a sandbox for thorough testing before loading into production.
I hope that this information was helpful in explaining the complexities of Salesforce packages in more detail. If you have any other package questions or nuggets of wisdom, leave a comment, we’d love to hear from you.
Photo Credit: Geek Philosopher
