It seems to me that, indeed, if there is one place to define permissions, permissions sets and groups offer a complete package. Any object or field level permission can be designated. So, for simplicity of design and ease of maintenance, it seems one should assign all permissions in permission sets, and none anywhere else. That way, you maximize their potential and don’t have to wonder why the actual effective permissions are different than what your permission set says they should be. So, in a purely "permission set world," would this not imply that all profiles should have no access to any object? And further, would not all field-level security settings be set to not just read-only, but invisible?
Here’s what I come up with for a strategy: all field level security set to invisible, all profiles created with no access to any object or field. Then I define permission sets for various levels and scopes of read-only and edit access. I try to keep these definitions reasonably narrow to retain flexibility but not so narrow as to become cumbersome. Then for standard areas of responsibility in my organization, define permission set groups for ease of management. As for profiles, maybe someone can answer why would I need more than one? I haven’t run into a reason yet.
Thank you in advance for your advice and comments.
Jim
3 réponses
Thank you, Amnon, for your advice. It seems to me the main limitation of profiles--and hence the advantage of permission sets--is that only one profile can be assigned to a user. Rather than simply select a certain combination of permission sets for a group of users, I have to create a fixed profile. I do see the wisdom in avoiding too heavy a reliance on permission set groups at this juncture, but they add a convenience to using permission sets, and need not be central to a permission set-based strategy. If the groups don't work out for some reason, the permission sets are still valid. At least this is how it seems to me.
Thank you again,
Jim
