Why This Is Worth Getting Right
Profiles, permission sets and permission set groups decide what your users can actually do in your org. Get them wrong and you’ve either got people who can’t do their jobs, or people who can delete things they shouldn’t be able to see.
They’re also one of the fastest parts of an org to turn into an unmaintainable mess, because it is so easy to solve today’s problem by cloning a profile. Do that eleven times and you have eleven profiles that are 95% identical and nobody knows which is which.
So let’s talk about how to set this up properly.
The Distinction Everyone Trips Over
Before anything else, this one, because it confuses almost everybody at first.
Object level access is what profiles and permission sets control. Can this user see the Account object at all? Can they create Accounts? Edit them? Delete them? That’s Create, Read, Edit, Delete, View All, Modify All, plus field level security.
Record level access is a completely different system. Can this user see the Edge Communications account specifically? That’s controlled by org-wide defaults, role hierarchy, sharing rules, manual shares and Apex managed sharing. Not by profiles.
So a user can have full Read access to the Account object on their profile and still see zero accounts, because sharing hasn’t granted them any records.
Two separate layers. Both have to allow it. If someone can’t see a record, work out which layer is blocking them before you start changing things, or you’ll grant object permissions that don’t fix the problem and quietly widen your security model for nothing.
The Three Tools
Profiles. Every user has exactly one. Beyond permissions, a profile also controls things nothing else can: login hours, login IP ranges, page layout assignments, record type defaults, and the default app.
Permission sets. Additive grants you can assign to any number of users. A user can have as many as you like. Permission sets can only grant access, never take it away.
Permission set groups. Bundles of permission sets you assign as one unit, usually mapped to a job role. They also support muting, which lets you switch off specific permissions that one of the bundled sets would otherwise grant.
The Approach I’d Recommend
Here’s the pattern that scales, and it’s also the direction Salesforce itself is pushing.
1. Keep profiles as bare as you can get away with.
Ideally one or two profiles for the whole org. Give them the absolute minimum, plus the things only profiles can do (login hours, IP ranges, layouts). A “Minimum Access” style profile as your baseline.
2. Put every actual permission in a permission set.
Build them around capabilities, not people. Manage_Opportunities. View_Financial_Data. Run_Reports. Each one does a specific job.
3. Bundle them into permission set groups by job role.Sales_Rep = Manage_Opportunities + View_Accounts + Run_Reports.Sales_Manager = everything in Sales_Rep + View_Team_Data + Approve_Discounts.
Now when a new sales rep joins, you assign one permission set group and you’re done. When sales reps collectively need a new capability, you change one permission set and every rep gets it.
Compare that to the profile-cloning approach, where you’d be editing eleven near-identical profiles by hand and missing one.
Why Not Just Use Profiles?
Because a user only gets one, so every combination of needs becomes a whole new profile. Sales rep who also handles support? New profile. Sales rep who handles support but only in one region? Another one.
That’s combinatorial explosion, and it’s how orgs end up with forty profiles nobody can audit. Permission sets compose instead of multiplying.
Salesforce has also been signalling for years that profiles are on the way down, with permissions steadily migrating to permission sets. Building this way now means less to unpick later.
Muting: Useful, But Handle With Care
Muting permission sets let a group switch off a permission that one of its member sets grants. So you can reuse a broad permission set in a group where you need most of it.
Genuinely useful. Also genuinely confusing to debug, because now a user’s effective permissions depend on the interaction between several sets and a mute. When somebody asks “why can’t I delete this?”, muting makes that a harder question.
Use it deliberately, document why, and don’t reach for it as the default answer. If you’re muting half of a permission set, that set was probably too broad to begin with.
Practical Rules
Name things properly. Manage_Opportunities tells you what it does. PS_Custom_2 tells you somebody was in a hurry. Fill in the description too, same argument as I made about field descriptions in the data dictionary post.
Be extremely careful with Modify All Data and View All Data. These bypass sharing entirely. They’re routinely handed out to solve a record visibility problem that should have been fixed with a sharing rule, and now that user can see everything in the org forever.
Grant the minimum that works. Boring advice, correct advice. It’s much easier to add a permission when someone asks than to work out later whether it’s safe to remove one.
Use the Setup Audit Trail. When permissions mysteriously change, that’s where you find out who did it.
Check what a user actually has. Salesforce has a genuinely useful feature for tracing why a user can or can’t see something, and I’ve covered how to instantly tell why a user has access to a record separately.
Wrapping Up
Minimal profiles, capability based permission sets, role based permission set groups. Remember that object access and record access are two separate layers. Be sparing with the god-mode permissions.
Get this right early and adding a new team is a five minute job. Get it wrong and you’re auditing forty profiles by hand in two years’ time.
Get Coding With The Force Merch!!
We now have a redbubble store setup so you can buy cool Coding With The Force merchandise! Please check it out! Every purchase goes to supporting the blog and YouTube channel.
Get Shirts Here!
Get Cups, Artwork, Coffee Cups, Bags, Masks and more here!
Check Out More Coding With The Force Stuff!
If you liked this post make sure to follow us on all our social media outlets to stay as up to date as possible with everything!
Youtube
Patreon
Github
Facebook
Twitter
Instagram
Salesforce Development Books I Recommend
Advanced Apex Programming
Salesforce Lightning Platform Enterprise Architecture
Mastering Salesforce DevOps
Good Non-SF Specific Development Books:
Clean Code
Clean Architecture
