Reasons to Use More Than One Profile in an Org

Question

I just started a project at a new company who is configuring a new Salesforce org. I've learned that they are planning on using only one Profile for what currently looks like 3 different personas (each persona has different CRUD needs on various objects).

They are planning on using Permissions Sets to control any/all access to objects. At the moment, the reason for this is "that's the way [our company] does it".

I know enough to know that this is unusual, and may have significant long-term costs that they're not considering (for example, Field Level Security can't be assigned via Permission Set), but need some 'official' list of reasons to use Profiles--along with Permission sets--to control object access for different personas.

Is there a list, for example, of Salesforce features that are only assignable (without code) using Profiles (like FLS)?

Better yet, any Salesforce-sponsored articles explaining why you'd use both, and not just rely on Perm Sets for everything....Or what the best practices are for using either, based on business requirement?

Thanks!

Answer 1

I much prefer this approach, to be honest. Profiles kept to a minimum and leverage permission sets along with permission set groups. Pretty sure Salesforce themselves would suggest the same now.

In the company I work for we are currently working on reducing our profile count.

Some things are stuck to profiles like org-wide-email-addresses being one and page layout assignments. So the approach we have gone with is introducing 2 base profiles, one for our customer-facing side of the business and one for our partner side of the business. Permset groups are then created as per different teams in the business. Out underlining permsets, are functionality based, and can be handpicked for the different perm set groups depending on which teams need what functionality.

Hope that makes sense! Fred

Answer 2

Permission Sets basically only allow you to add Boolean permissions. For example, you can't assign Password Complexity Requirements, Default Record Types, or IP and Login Time Restrictions, since there are many possible values.

Basically, looking at a Profile, if you can check a box (not including radio buttons), you can do this with a Permission Set as well. I don't know of an exhaustive list, but most of the things you can't set in a Permission Set are Security Controls and User Interface configurations (e.g. Page Layout Assignments).

That said, the idea some of us have come up with that looks reasonable would be to have each Profile encompass core features that can only be set by Profiles, then have Permission Sets per major app/core system feature (e.g. a Permission Set for Roadside Assistance, Call Center, etc), and then Permission Set Groups for Personas (e.g. Call Center Agent, Call Center Manager, etc).

This setup lets you easily control Page Layout Assignments for various types of users, and enable/disable certain apps per Persona, and update those apps for all Personas that use them. This should minimize downtime in most cases.

So, in summary, one Profile if you can, but most orgs will likely need two or more profiles to accommodate security controls or UI configuration, but Permission Sets and Permission Set Groups should be used as much as possible.