Keep Up with Upgrades and Add-ons
Learning Objectives
- Define edition upgrades and add-ons.
- Explain why an admin needs to update profiles and permission sets after the customer org purchases an upgrade or add-on.
- Explain how a customer can keep their sandbox orgs in sync with their production org.
About Edition Upgrades and Add-ons
When you first sign up for Salesforce, you choose the edition that best fits your business needs at the time. As the business grows, you may need to take advantage of more advanced Salesforce functionality.
An edition upgrade happens when your org transitions to a higher Salesforce edition. For example, Ursa Major Solar started out with Enterprise Edition. As the business grows, the company may decide to upgrade to Unlimited Edition, to get advanced capabilities for creating custom apps.
An add-on supplements your org with additional features or services, without changing the edition. We looked briefly at add-ons in the first unit, when Ursa Major Solar supplemented its Service Cloud Enterprise Edition with the Service Cloud Einstein add-on.
Upgrades and Add-ons: Admins Take Action
When you purchase an edition upgrade or an add-on, your org gets one or more new platform, user, or permission set licenses, or possibly some combination of each. And, as with a new org, as an admin you take actions with an upgrade or add-on to make sure that the right users get access to the new features. You should review the relevant permissions that users need to access the new functionality and make assignments to grant user access. You may need to assign new user licenses, permission set licenses, and profiles. Or you may need to create and assign new permission sets, or add permissions to existing permission sets.
When Ursa Major Solar purchases the Service Cloud Einstein add-on, admin Maria Jimenez assigns the Service Cloud Einstein permission set license to account executives like Lincoln Ulrich, who need to access the Einstein artificial intelligence features. Lincoln and the other Ursa Major account executives were already assigned the Full CRM user license. The Service Cloud Einstein permission set license is in addition to the assigned user license.
After she assigns the permission set license, Maria then assigns the Service Cloud Einstein standard profile to those same account executives to enable the functionality in the permission set license. If Maria needs to further modify the Service Cloud Einstein permission set license for some users, she can create a Service Cloud Einstein custom profile. Or she can create a permission set that supports the additional functionality. Then she can assign the custom profile or the permission set to users who need the additional functionality.
Pushing License Changes to Sandbox Orgs
Most Salesforce editions include the ability to create one or more sandboxes, replicas of the production org that serve as staging environments where you can test changes without affecting the production org or users. When you update licenses through an upgrade or add-on, you will usually want your production and sandbox orgs to be in sync. When you make any changes to production org licenses, you must push changes to the sandbox orgs if you want your test environment to mirror your production environment.
In many cases, you can refresh the sandbox org to make sure that its licensing information matches the production org’s. Refreshing a sandbox updates the sandbox’s metadata from its source org (the production org used to create the sandbox). If the sandbox is a clone or if it uses a sandbox template, the refresh process updates the sandbox org’s data in addition to its metadata.
To ensure that sandbox orgs receive updated license information, customers can use the Match Production Licenses to Sandbox tool. With this tool, you can match all provisioned changes in the production org to the sandbox org, without having to refresh the sandbox. Matching updates the sandbox license counts to match the production license counts. Matching also adds licenses that are in production but not in sandbox, and deletes licenses from the sandbox that aren’t in production.
Keep in mind that the sandbox and its corresponding production org act as independent orgs. For example, if you create new objects in the production org after refreshing the sandbox, those objects aren’t synchronized into the sandbox until you refresh it again. The sandbox has the same behavior—new objects that you create in the sandbox aren’t automatically synchronized to the production org.
