I'm thinking of using PSGs for an ISV use case once they go live. I wanted to ask if this seems like the optimal solution to our use case?
Currently we are helping support an app that installs two packaged permission sets, one for the Admin role and one for the User role. However the Admin can also take actions in our setup UI that result in some auto-generated Visualforce pages that should be available to both user groups. These VF pages cannot be added to the packaged permission sets because they are unpackaged metadata.
Without PSGs our options are limited. We could create a third PS but then we have to deal with syncing user assignments back and forth. Currently we just remind the Admin to please ensure the new VF pages are added to the profiles of the users they expect will use them.
I assume that a packaged PSG cannot have an unpackaged PS added to it (but tell me if I'm wrong!). So what I was thinking we could do with PSGs is:
- In our Post-Install Script, or perhaps on click of a button in the Setup UI, we create an unpackaged Admin PSG and User PSG
- We add the Admin PS to the Admin PSG, and add the User PS to the User PSG
- We create an unpackaged "Custom Pages" PS, and add it to both PSGs
- Any time we create a new VF page they need access to, we add it to the Custom Pages PS
Then instead of asking the admin to add users to the Admin & User PSes, we have them add users to the PSGs.
Any thoughts?
@Sharon Liao The use case is, the administrator can use the app to attach our app's capabilities to any object in their org. If the object they choose is not one of the standard ones we packaged support for, then we give them a "setup helper" tool where with one click they can deploy the buttons and VF wrapper pages necessary to support the integration for those objects. (These are thin wrapper pages around a packaged VF component, exclusively to deal with the restriction that VF pages on object layouts must implement the object's Standard Controller.)
Currently the permissions model is simply, we package a User PS and an Admin PS, and the admin puts the necessary users into each PS. However a current gap in the package is, when the admin uses our setup helper to create the VF pages, we have no way to automatically ensure the VF pages are visible to the same users they have already authorized as app users (and the ones they will authorize in the future). This is because we can't add the newly created (unpackaged) VF pages to the packaged Permission Sets.
When PSGs go GA, we'd have an avenue for keeping it synchronized. We could refactor from having admins add users directly to the PSes, to instead having them add to the PSGs. We could add wording to the "setup helper" to explain that when the admin clicks to create a VF page, it will be added (via a local PS) to the same Permission Set Groups they are already using.
