Considerations for permission sets and installing Apps or packages in Professional Edition orgs
|Knowledge Article Number||000220361|
|Description||When trying to install Apps or packages in Professional Edition (PE) orgs, installers are not prompted to set permissions for different profiles and access is provided to all users by default. Package access has historically been "Install for All Users" by default in PE orgs and this is working as intended since PE does not include access to profiles.
Partners and application vendors need to be mindful that permission set access for PE orgs was not intended or designed to be a means to circumvent the default access set on install and they should not add permissions sets as package components for this purpose.
|Resolution||The purpose of allowing the creation of one permission set in PE orgs was only intended for native use by customers within the org itself and was not designed to be consumed or utilized by partner or vendor packages or apps.
Permission sets included in Aloha certified packages are exempt from the 1 permission set limit in PE orgs. However, users may find that they're unable to install a non Aloha app or package containing a permission sets if one has already been created in the installation's target or subscriber org and conversely, customer's may not be able to create a permission set if they've installed a package that includes a permission set as a package component.
However, we understand this concern/feature request from ISV partners, so it is recommended to create or promote changing this via an Idea Exchange post so that we may see this behavior altered with a future release.
When I install a package that’s listed on the AppExchange, do custom objects, tabs, and apps in that package count against the limits of my Salesforce Edition?
See Which Apps, Tabs, and Objects Count Toward Organization Limits