I am developing a solution which should be reused for more customers of my client . It makes sense to me to create a managed package (second generation), which will be distributed to them (most of the cases will be fresh installation of salesforce owned by my client not his customers). My question is how it can works with communities. Solution will contains 2 or 3 communities. I found Bolt solution, but it's only templates used to create community, and I will have probably new version of solution at the end of 3 weeks sprint. I haven't found how to update community with managed package. Can Second generation manage package contains community?

My current workaround is to continue use git as source of truth, and use it to distribute code to all orgs (it will be maybe 2-5 production orgs, but maybe 10 testing sandboxes).

Thank you for each opinion if managed package should be used, or git.

2 Answers 2


You cannot package a Community in any generation of managed package.

As you've already found, you can package entities like Community Templates and Bolt Solutions, including many of the components that make up the final Community in the subscriber org. But you cannot package the Community itself.

If you upgrade a package containing a Lightning Bolt Solution, the Solution is upgraded. However, the original version of the template remains in the org (albeit not available for creation of new Communities). I believe, although I haven't confirmed this hands-on, that Communities created from the original version of the Solution retain the original template (excepting any components, like Lightning components, that are themselves upgraded and overwritten by the new version).

Thank you for each opinion if managed package should be used, or git.

This is not an either/or. You can use a managed package with Git as its source of truth, and you can also store unmanaged metadata and/org automation scripts in Git.

My organization, Salesforce.org, delivers multiple managed package products that include in their installers setup automation to build a Community from packaged components (one free product is Outbound Funds Fundseeker Starter Portal). However, I think updates to existing Communities is a problem we've never tried to solve directly.


I asked a similar question on the Partner Forums and got the following response (tl;dr):

Unfortunately we do have experience with community templates (in 2GP). Communities spun from a community template cannot be upgraded when the template has been upgraded. Community templates can only be generated through setup. After you have generated a Community Template you cannot generate it a second time. You first have to delete it. Deleting it and then recreating it, doesn't work because metadata will be deleted that is propably in your package. Furthermore, we have discovered an astonishing number of defects in Salesforce which have been acknowledged by Salesforce as being defects. I wouldn’t advise a customer (we are an AppExchange App Development partner aka PDO) to add a community template to a package. Normally I am quite bullish about Salesforce technology but in this case I am definitely more bearish.

As an alternative you could consider to develop a 2GP unlocked, unnamespaced extension package on top of your current package. This package would contain a community (in the form of an experience bundle) that would serve as the template. Since it is unlocked, customers can change the community. You could even upgrade the 'template' through push upgrades although that most likely would overwrite changes the customers himself made. We have applied this pattern at a number of OEM customers quite successfully. Still, community cloud has a number of issues in it which sometimes confronts you with unpleasant surprises. To name a few:

  • If you add an experience bundle/community to a package and then try to create a package version from it, Salesforce will generate a number of classes (like MyProfilePageController and MyProfilePageControllerTest) during the packaging process with tests that in certain cases fail (namely when you have state and country picklists enabled in your scratch org definition file you use for packaging).
  • If you have a community template in a base package and a community with the same name in an extension package, the community pages cannot be changed.

I can go on and on but it has been a 'discovery' for us.

The upshot is that you are best to package this as a Digital Experience in an unlocked package. You can find a bit of detail about the metadata you need from this help article. You need to enable experience bundles on the org you develop this against in order to allow sfdx to be able to pull the metadata.

Note that all metadata in an unlocked package is developer upgradeable (AFAIK) and installing an upgrade will overwrite subscriber changes.

BTW, it is necessary to have a step before installing the package to create an empty version of the digital experience since you cannot actually package the "site" part (which therefore needs to be created directly and first).

You must log in to answer this question.

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