Salesforce’s ability to extend your organization’s functionality is one of its most compelling features. Since every Salesforce client might have drastically different needs and use cases, the platform must be customizable. Traditionally, this customization was done internally by developers and system administrators. But besides salesforce’s inherent configurability, it can also be extended through bundled applications, components, and other customizations created by others via Salesforce Packages.
What is a Package?
If you have been in the Salesforce, you must have seen this term widely used, but not everyone knows what it means and its different types.
It’s a container that can be used for a small, individual component and a large set of related applications. Salesforce Classic (not in all Organisations) and Lightning Experience support it. A package consists of components that specify items, including custom objects and custom fields. You can design useful functions and applications by combining different components in one package. In turn, components include attributes that represent fields on the components, e.g., the unique name of the dashboard or the Allow Activities checkbox on a custom object. The package can be downloaded and installed in Group, Professional, Enterprise, Performance, Unlimited, and Developer Editions.
There are two types of packages, Managed and Unmanaged, which will be discussed in the following part of the blog.
What is a Managed Package?
Salesforce partners generally use Managed Packages to distribute and sell applications to customers. As with most apps, the end user gets all the product’s benefits but does not have access to its source code. These are created by Salesforce themselves or their partners and can be listed on the Salesforce AppExchange using the License Management Application (LMA). It automatically updates the code when upgraded like your operating system.
There are three versions of managed packages:
Beta: A version of the managed package for application testing
Released: The package is live on the AppExchange and publicly available
Installed: The package is installed from another Salesforce org. but managed
What is an Unmanaged Package?
Unmanaged Packages are open source, one-time distributions that anyone can modify. You can move components between organizations even if they are unrelated. However, once a new version is released, it cannot be upgraded, so you may need to reinstall it in a new organization. The best time to use unmanaged packages is when your apps require custom settings after installation.
Key Differences between a Managed Package & an Unmanaged Package:
Attributes |
Managed packages |
Unmanaged Packages |
Users | The Salesforce partner ecosystem typically uses managed packages to sell applications to customers. | Unmanaged Packages are typically used to distribute open-source projects or application templates to provide developers with the basic building blocks for an application. |
Customization | You cannot view or change menu code or metadata like Apex Class, Trigger, VF Page & Lightning Component, etc. | Customization of code and metadata is possible. |
Upgradation | The provider can automatically upgrade the offering. | Getting an update message requires uninstalling the package and then reinstalling the new version from AppExchange. |
Organization limits | Packages do not count against the app, tab, and object limits | Package contents count against your organization’s app, tab, and object limits. |
Security | Highly protected and secure from data threats.
|
High risk of data loss due to insufficient control. |
Conclusion
We hope by now you must have been clear about both the terms and have even understood how they differ from each other. But you can still be sceptical about when to go for managed packages and when to go for unmanaged packages. Although there are many scenarios where using an Unmanaged Package can be profitable for your organization. Yet, data is by far the most important thing involved with Salesforce. Since it exposes your business to the risk of potential data loss, adopters must proceed down this path with caution.