August 28, 2018
Managed Packages in Salesforce – The CoreValue Experience
The most powerful characteristic of the Salesforce platform is its extendability. From minor configuration tweaks to custom built functionality, it surpasses the out-of-the-box domain of capabilities. Salesforce has addressed the challenge of meeting the requirements of a wide spectrum of potential customers, by making rich customizations possible.
As the complexity of customization increases, there is a need to recognize distinct feature extensions, control their area of responsibility, and keep track of their respective components and dependencies. The possibility of deploying, porting, disabling, versioning, etc. the features created as extensions of the standard platform, as logical whole elements, is required.
A pillar of the Salesforce customization mechanisms, which addresses those needs, is the AppExchange Application, or managed packages.
The main purpose of a managed package is to bind code and configuration elements into a single entity. Those can be logical functional modules, re-usable code libraries, or entire sub-systems containing the functionality of a business channel.
A good analogy for AppExchange is the AppStore for iPhone or the Plugin Marketplace for the Eclipse IDE. When a managed package is publically distributed through AppExchange, it becomes a universal product, which may be installed safely on any instance of a Salesforce org. The AppExchange packages have powerful mechanisms of encapsulation and security, protecting from interfering with any local customizations of a given org or other managed packages. Managed package defined dependencies allow one managed package to further extend another.
In technical terms, another way to look at managed packages is to compare them to Java JAR and WAR containers. Managed packages protect their own codebase and components; they run in a separate execution scope with extra governor limit resources allocated; they can be versioned, disabled, rolled-back or updated, all independently of the rest of the Salesforce org.
This is the only name-spacing mechanism, which Salesforce provides. It is used to split large codebases and numerous configuration elements into manageable chunks. This allows projects to grow sustainably.
Managed applications usually communicate through interfaces or access each other’s database elements directly, when specifically needed, by means of dependencies. The mechanisms of encapsulation, enforced by the platform, limit failure points, preserve functional integrity and protect private elements. They also allow managed packages to use an extra number of elements, regardless of the type of Salesforce environment. For example, custom objects from a managed package do not count against the total limit of an environment.
Managed packages are invaluable for:
- Delivering similar, but locally customizable functionality, across multiple Salesforce orgs; i.e., as a means of promotion for customers, which use multiple orgs for segmentation purposes (business channels, geo regions, etc.).
- Generic products with independent functionality for multiple customers.
- Reusable code libraries with protected source code.
- Generic products which allow local implementations to extend the functionality and achieve customer-specific implementations (plug-in approach).
The development of Lightning Components, as individual managed packages, is greatly encouraged by the platform and Salesforce practice guides.
So how does it really work with managed packages in AppExchange?
Managed packages, as a collection of application components, are typically used by Salesforce partners to distribute and sell applications to customers using the AppExchange.
Salesforce’s AppExchange is like a marketplace for your products. It helps companies to convert their ideas into a working product with an environment that manages subscriptions and updates. Having a vendor who is experienced in the development of a managed package, for AppExchange, is crucial. The publishing process includes a review stage by Salesforce, as an improperly chosen approach may result in a rejection from the Salesforce’s side and even a requirement to completely rebuild the app. It starts from the development standards and front-end technologies, moving up to the security requirements in the code.
You might have come across a situation where a company with multiple Salesforce orgs, for different countries or business units, uses a variety of managed packages. Both abstract and feature based managed packages can be implemented with the combination of packages and/or a different set of functionality for different business units, and at the same time have a good reuse of common functionality. Some packages can provide UI features, while others have integrations with backend office. And also as an additional solution, an API ecosystem can be built in order to stream the data from different instances into one place for managers that do not need access to each Salesforce environment.
Have a look at other cases.
We developed a Salesforce solution (CRM system) for reviewing statistics and managing data collected by sales field teams, with the mobile app that will give an overall view of the performance of sales and marketing campaigns through analyzing this information. This CRM solution is aimed at building graphics and calculating performance indicators, which allow users to review reported information without having to work on some kind of reporting files.
The project scope included:
-Managed package for AppExchange.
-Release and support of the product.
-Migration to a new architecture when moving the functionality from web application to Salesforce.
Our own product Trigger Control is published on AppExchange. We provided a framework for developers to organize the order of trigger execution, especially in managed packages, as well as an easy option to configure their composition.
CoreValue Expertise with Managed Packages
Development of the functionality, using managed packages, is becoming more and more popular. We’ve been working with the packages for over 5 years starting from the product companies that built their markets based on the product via a managed package, up to big international enterprises that require a similar functionality to be installed on numerous Salesforce orgs. The development of the functionality this way is not easy and can result in over engineering, if the team is not experienced enough. Through the years we’ve gained extensive experience in both managed and unmanaged packages, as well as the development of the systems that use dependent packages to provide main functionality and org-to-org extensions, for different business units.
Managed packages are useful to organizations that are introducing a single solution to a number of instances on the Salesforce platform. Though there are some limitations, we aim to protect customers from any changes that induce data loss, functionality failure or incompatibility with previous versions. With the well-modelling of an experienced architect solution, the entire implementation is seamless and comfortable.