I have two managed packages which is built by our company. Both these packages have a lot of code which is common to both the packages. Sometimes both the packages are installed by one client. There are some objects which are used by both the packages, so if a client installs both the packages then there are two objects with the same functionality and name which might be a little confusing unless you see the namespace.

I am trying to see if there is an architecture wherein we are able have a common library from which both the packages can source the common functionality.

  • Did you try extension package ? Commented Feb 26, 2016 at 20:15

4 Answers 4


The proper design would be to have the two packages be "extensions" of the core library. This would require all clients to install two packages to use either app, and three packages to use both apps. While slightly more complicated for installs (and possibly undesirable), it would allow you to maintain less code and configuration.

Here's how it works: you create three developer orgs, and a managed package inside each of them. The base package is placed in the first org, uploaded to the AppExchange, and then installed in the other two orgs. Each of those two orgs can then reference the code, objects, and fields of the installed version, which will make those packages "extension" packages when they are uploaded to the AppExchange. Finally, get everything through the security review, and you're ready to start letting people use your packages. In each of your listings, you'll want to provide pre-install instructions (namely, installing the core library).

Note that you'll be operating in (up to) three namespaces, and only 10 are allowed per transaction, so you may need to notify your clients of this requirement. For example, if they have 8 installed packages that use Accounts, and your three packages also use Accounts, then installing the packages will cause errors. Finally, also note that the "base" library would necessarily have global identifiers, so there may be some leak of your library code. You can get around this by having the global classes call public classes to avoid exposing IP, if that's a concern.

  • Makes sense in theory. But have you ever seen this done or done it yourself?
    – Keith C
    Commented Feb 26, 2016 at 23:01
  • 1
    @KeithC I did do this once before in a previous life, once on purpose and once on accident (oops!). It's actually a pretty slick setup once you get going, but it requires a lot of planning and forethought (at least as much forethought as a managed package itself). Since you can't easily undo mistakes, especially in the core package, lots of planning is recommended. Not a very agile-friendly experience, to say the least.
    – sfdcfox
    Commented Feb 26, 2016 at 23:22
  • @KeithC Also, now that I think about it, I remember seeing an AppExchange app that had a core package, and then extensions which they called "license packages" (so, the core actually contained all the logic, and each additional managed package would do something to enable the logic for some part of the core package).
    – sfdcfox
    Commented Feb 26, 2016 at 23:25
  • Thanks for those comments. When I've put pieces in one package to use in another package its been a real pain when a change is needed between the two because the package creation/installation can take so long. So good to know it can pay off sometimes.
    – Keith C
    Commented Feb 26, 2016 at 23:49
  • @sfdcfox thanks for the detailed explanation. All the three packages would be needed to go through security review and if its paid then all three probably need to pay the security review fee as well. I think i might stick to two different packages for now.
    – Prady
    Commented Feb 27, 2016 at 7:05

If the primary pain point is the duplication of code (not the duplication of objects or fields) then an approach is to create a separate project in your version control system for the common code. You can then add that code to both packages using mechanisms such as svn:externals via your IDE. So each managed package gets an identical copy of the code.

This avoids introducing global signatures which then can't be refactored which in my experience is a big problem in managed packages that are being continuously developed. And there is no need for the third package. However if the code is referencing objects then you end up with lots of dynamic SOQL and map-like references to fields.

  • Its a combination of duplication of code as well as duplication of object that is what i wanted to avoid. I just think at this point i would have two different packages and possibly rename the objects a bit differently in each object as i feel there is too much uncertainty or unknown with the core library approach. Thanks for the insights
    – Prady
    Commented Feb 27, 2016 at 7:01

We do exactly this...we have a shared base package with common SObjects, Apex classes, Visualforce pages, remote site settings (all of our apps are hybrids and make callouts to the back end), permission sets, etc., and we have multiple extension packages that represent the actual applications. The SObjects in the base package generally represent shared configuration objects for our applications as well as the UIs for those objects in the form of Visualforce pages and Apex controller classes. The base package also contains a number of common Apex utility classes and the declarative authorization model in the form of packaged permission sets.

There are definitely pros and cons to this even ignoring the additional security review overhead. On the positive side, for the most part we do get the desired code and data reuse. I qualify "for the most part" because some limitations and even bugs in the Salesforce packaging model keep us from taking full advantage of this like we would in a language with a more well-defined, granular packaging model. There are workarounds for most of these, though some do require limited clone-and-own or even additional onerous steps at packaging time.

On the negative side, development of multiple managed packages with base/dependency relationships can be a serious pain! The most obvious approach is to do this in multiple dev orgs, one-per managed package, and go through a constant cycle of deploying, uploading, uninstalling, installing, and deploying. By the way, when I say "multiple dev orgs", I mean multiple per-individual contributor plus multiple for testing and of course for releasing. With this approach, cycle times can be very long to test a change that crosses both packages. We've since figured out how to develop content for multiple packages in a single dev org. This definitely helps with the development process, but it comes with its own issues since it doesn't model the real production deployment topology. If you'd like more information, I spoke about this in detail at Dreamforce 2014:


I agree with the poster above that if it's almost exclusively code that you're needing to share, having a common repository for that in source code management that is mapped into each package at build/packaging time is an option that you should consider. If, on the other hand, like us you really need to share persisted state between applications and that persisted state must live in Salesforce, you probably need multiple managed packages with base/extension relationships like this. I guess a third option might be more along the lines of a microservices approach where you have peer packages (vs. base/extension) which communicate with one another via SSO, though you're going to need to work through the security implications of that very carefully. Also, this would almost certainly need to be more coarse-grained than any real microservices approach to avoid an unmanageable explosion in the number of managed packages.

I'm happy to share more about our experience with this if you're interested. Just let me know...


One way to go about it would be to see if App B could actually be modeled as an extension to the other App A.

In other words, you'd ship the (likely) best-seller App A as your basic application with its core code and then provide that other App B as an extension to it.

Of course, this creates a dependency between App B and App A, so you wouldn't be able to just install App B standalone.

Having your two apps as of now, you could designate App A as your base and create a new App C as an extension to that so as to replace App B for which you would plan to not provide further support in the long run and point to App C instead.

Other than that, I think it would be great if the force.com platform catered for managing a managed package through different licenses.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .