Rolling out an add-on takes contract action, provisioning, and the standard permission-assignment loop. The mechanics are similar across add-ons; the differences are in which permission sets and PSLs the specific product uses.
- Confirm contract and provisioning
The add-on must be on the contract and provisioned by Salesforce. Check the Permission Set Licences page in Setup. If the PSL is not listed with a non-zero count, contact the AE or partner CSM before going further.
- Assign the Permission Set Licence
Setup, Permission Set Licences, click the PSL, then Manage Assignments. Assign it to the pilot users first. PSL assignment is the gate; permission sets without the PSL will not grant the add-on permissions.
- Create or clone a permission set
Most add-ons ship with one or more default permission sets. Clone the one closest to your needs, name it for your org's convention, and adjust object and field permissions to match your role model.
- Pilot with a small user group
Assign the permission set to five to ten users. Watch how they use the add-on for two to four weeks. Adjust setup, automation, and training material based on what you learn.
- Roll out broadly and track utilisation
Once the pilot validates the design, assign the permission set to the wider audience. Build a usage dashboard (logins, feature interactions, key actions) to prove value and to inform the next renewal conversation.
- Permission Set Licence assignment is required before the permission set takes effect. Assigning the permission set first without the PSL gives users an error.
- Over-assigning PSLs is now blocked at the platform level. Reorder more seats before rolling out beyond the contracted count.
- Some add-ons require a sandbox refresh after provisioning to make the feature visible in sandboxes. Plan dev work accordingly.
- Add-on availability varies by edition. A few add-ons require Enterprise or Unlimited even after purchase. Confirm prerequisites before signing.