One of the features that makes Salesforce so formidable is the power to extend your Organization’s functionality. Since every Salesforce client could potentially have drastically different needs and use cases, it is imperative for the platform itself to be customizable.. Traditionally with other software, this customization was done in-house, if at all possible; developers and system administrators would need to create the functionality manually themselves. With Salesforce, not only is configurability at the heart of the platform, it can be extended by using bundled applications, components, and other customizations that others have created via using relevant Salesforce Packages. We’re going to examine a couple options you have, as an admin, when you’re choosing to leverage a bundled Package to enhance the functionalities of your org.
What Is A Package?
A package is a collection of components neatly bundled up to solve a certain use case. A component is an item in the package, with attributes that define it. These components can be anything from custom objects, fields, page layouts, tabs to custom code, or even Lightning Web Components. By combining multiple components together, powerful applications can be created. Whether simple or very complex, these applications can be used to improve the quality of life of the users of the org with the simple click of an “Install” button. If you have ever installed an app from the AppExchange then you have worked with packages. Being able to utilize packages is a must-have tool in any Salesforce Developer or Admin’s toolbelt.
Keep in mind that not all packages are created equal. There are a few different flavors of packages such as managed, unmanaged, unlocked, and org-dependent unlocked. In this post, we’re going to discuss the two main, high-level types of packages, managed and unmanaged. There are some major differences and implications between these two, so it is very important to know when to use either.
What Is The Difference Between Managed And Unmanaged Packages?
Managed Packages are either created by Salesforce themselves, or their partners, and can be listed on the Salesforce AppExchange. Unmanaged Packages are not approved or listed on the AppExchange. To be Salesforce approved, Managed Packages go through a rigorous security review to ensure the components within are safe and don’t jeopardize the security of its user’s orgs or the data contained within them. Unmanaged Packages, on the other hand, don’t have to pass any kind of security review. Unmanaged Packages are a bit more like the wild west. They can be a dangerous place, but could also provide a lot of opportunities. Let’s take a deeper look into some of the differences between the two.
If we assigned a score to the packages via the list above, it would look like managed would secure an easy win, right? They are safe, upgradeable, and Salesforce-approved! On paper, they seem like the obvious choice. Well, not all situations are so simple. There can be times where the less secure, more wild, and untamed package is what is needed.
Why Use Unmanaged Packages?
There can be some scenarios where using Unmanaged Packages is a great option. The most appealing thing about them, especially to Salesforce Developers, is that they are open source! Being open-source allows for customization. With that being said, there are many other situations where it might be beneficial to use the Unmanaged Package, here are a few.
For example, what if there is nothing on the AppExchange for your desired solution? You could find an Unmanaged Package that has some of the business logic you are looking for and update the code to fit your unique business use case. Unmanaged Packages can often act as templates which developers can then customize to fit their business needs. Being able to build on top of already written code provides flexibility and extensibility for developers.
With Managed Packages, the code being upgradeable sounds like a good thing right? In many situations it is. Receiving updates can be great for bug fixes and new additions. But what if you don’t want the package publisher to push the new updates? Well, you don’t have much of a choice. If the publisher releases a new version of the Managed Package, you may be automatically updated - this varies by publisher. This could potentially change in-package functionality and features to perform in ways you didn’t expect. You are at the will of the publisher with Managed Packages. With Unmanaged Packages, the original dev no longer has control or ownership, it is owned by the installer! This can be a double-edged sword if you decide to use an Unmanaged Package because you are now responsible for all bug fixes, enhancements, and new features yourself.
If you inherit a project or org that is using Managed Packages, and problems or bugs arise, you have to wait for the publishers to fix them and release a new package version instead of going in and fixing the problem yourself. This could potentially set your own projects back months. Also, publishers often stop supporting their packages. So not having to depend on others can be a great benefit of using Unmanaged Packages.
Lastly, let’s say you have a short timeline to get an important component to users. You want to use a new Managed Package that is in development. But this can take quite a large amount of time to be able to reach the end-users. It has to be made in a developer org, pass security review, listed on the app exchange, and then finally be installed in the destination org. While an Unmanaged Package on the other hand can be much faster to launch. In time-sensitive situations, it might be wise to find an Unmanaged Package instead of waiting for the creation of a managed one.
In conclusion, there are many scenarios in which using an Unmanaged Package can be beneficial for your org. However, data is by far the most important thing involved with Salesforce. Since the Unmanaged Package route offers a higher risk for data security issues, adopters must proceed down this path with caution.
Comments