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?


  • Welcome to SFSE, and great first question!
    – Adrian Larson
    Sep 15, 2021 at 0:59

2 Answers 2


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

  • 2
    Hi Fred, and welcome to SFSE! This is a very good first contribution, and hopefully we'll continue to see you around. If you haven't already, please take a moment to read about How to Ask, How to Answer, and take our tour to get familiar with how we work. One small note, though: please don't "sign" your posts; we already know who you are, because your name is automatically displayed at the end of every question, answer, and comment.
    – sfdcfox
    Sep 14, 2021 at 22:26
  • Good point about page layouts.
    – Adrian Larson
    Sep 15, 2021 at 1:00
  • Hi, Fred. Thanks for the response. My concern was that certain native Saleforce features - Like Field Level Security - might essentially be rendered useless in the future, since (in the case of FLS) there's no option to assign field access to any other object other than Profiles. I'd imagine that over time you'd end up with dozens of Perm Sets, and if you wanted to open up access to a single field, would need to carefully managed (outside of SF) all of the PSs, and which fields each gives access to. Have you found that to be an issue, once you're a few months/years into deployment?
    – Bob Mount
    Sep 17, 2021 at 12:59

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .