Deploying a Salesforce Community with Change Sets

In preparation for deploying a community this coming weekend, I thought I’d share some knowledge around migrating a community through change sets. It’s been one of the biggest time-saving features Salesforce has invested in to-date, and they’ve only been making it better and better. It’s been available since Summer ‘18 and they made more improvements to it over the Winter ’18 release. The ability has made life SO much easier for those of us neck-deep in community deployments.

How do I migrate a Salesforce Community with change sets?

So you’ve created, configured and tested your community in the sandbox and are ready to go live with it in production. Where to start?!

  1. Create the new community in production, being sure to name it exactly what you named it in your sandbox (see “What to Watch Out for” below).
  2. In your sandbox, go to Setup | Outbound Changesets | Press “New” button to create new change set.
  3. Press “Add” to add components
  4. In the dropdown, select “Network” and add the component that matches the name of the community you wish to deploy, then press “Add To Change Set”.
  5. Press “View/Add Dependencies” button and find two files, both of Type “Site.com”, select them and press “Add To Change Set”.
  6. Now you should have 3 components in your change set, one Network and two Site.com:
  7. Add any other components you need and press “Upload”
  8. If you have custom lightning components or any new objects, configuration etc. that go along with your new community, I recommend creating separate change sets for those and deploying them first. That way your new community will simply pick all those processes up when it lands at the end.
  9. Select your receiving org (production), go to Setup | Inbound Changesets  and locate the changeset you just deployed.
  10. Validate and deploy.
  11. Do any manual configuration required, test and publish!

What to Watch Out for When Migrating Communities with Change Sets

  • You must have an existing community in the receiving org. Change sets will not create the community for you.
  • This existing community must have the same name as the one in the sending org, or you’re gunna have a bad time.
  • The existing community must match the same version as what’s in your sandbox. For example, if your sandbox is on Summer ’18 and your production is in Spring ’18, you’re gunna have a bad time.
  • The existing community’s pages will be completely overwritten. Any creation, update or deletion of content or pages will be applied to the receiving org’s community.
  • Custom list views will need to be brought over in the change set, and because they’ll have a different ID in the new org, you’ll need to reassign them in your community on list pages, list components, and in your navigation.
  • Individual page variations will come over, but the audiences and what variation they are assigned to will need to be re-created
  • Languages will need to be re-created and translations applied as well.

I hope this helps shed some light on migrating communities between orgs. I know having the step by step in front of me during deployment helps ensure I don’t miss anything.

Have you encountered any “gotchas” during your deployment with change sets? Share them in the comments below!

Originally posted on Perficient’s Salesforce blog.

Leave a Reply

Your email address will not be published. Required fields are marked *