Aller au contenu
SteveTechArcSteveTechArc Courses

Lego Blocks, Not Too Small

Ce contenu n’est pas encore disponible dans votre langue.

Module 2 of 7 in the chapter Profiles, Permission Sets and Permission Set Groups, chapter 3 of Securing Salesforce: Sharing and Visibility. Each module stands on its own.

The question this module answers: How big should a permission set be, what kinds of permission sets are there, and how many can an org have?

Here’s a question I like to ask a class. If you open the permission sets in your org, how many do you see?

Some people say five. Some say a hundred. And now and then someone says 90, and the room goes quiet. Because everyone knows what that means: somebody, some day, has to work out what one person can actually do.

Module 1 took the access off the profile. This module is about where it goes, and how to keep the new home from turning into the old problem.

Many of something

Section titled “Many of something”

The rule from module 1 still holds: if a user can only have one of something, it’s on the profile; if a user can have many of something, it’s on a permission set. A user has one profile and can have many permission sets, and each one adds access. None of them takes access away. When two permission sets both turn on the same permission, the user simply has it. That’s additive, and it’s what makes them work as building blocks.

I think of them as Lego building blocks. The old profile was one solid piece: to change one part, you made a whole new piece. Permission sets are small blocks, and you build each person’s access from the blocks they need.

Salesforce gives the sizing rule in one line: “Apply permission sets to users based on the tasks that they do rather than their job title” (Guidelines for Creating Permission Sets and Permission Set Groups (opens in a new tab), Salesforce Help, checked 2026-11-01). Its own example is a task: some sales users can read, create and edit leads, and some also need to delete and transfer them. So you build a permission set for that task, with delete on leads and the Transfer Leads permission, and give it to the users who do that task (Create Permission Sets (opens in a new tab), Salesforce Help, checked 2026-11-01).

A job title is a bundle of tasks. Bundles are what permission set groups are for, and module 3 builds them. Module 3 also shows where the blocks come from: every team that builds a subsystem ships at least three permission sets for it, read-only, user and admin.

The Lego nightmare

Section titled “The Lego nightmare”

Now the other end. I once had a client that suddenly had 90 permission sets. Every request had become a new permission set, because a new one was the fastest thing to deploy. And then, to decide what one human could do, you had to assemble a massive Lego set from 90 pieces. They had turned the profile proliferation problem into a Lego nightmare.

That client wasn’t unusual. One consultancy described an environment with “over 1,100 Permission Sets” and “nearly 100 Profiles” (Managing Salesforce Permissions at Scale (opens in a new tab), CapTech Consulting, 2024-09-10, checked 2026-11-01). That’s both problems at once.

So the goal isn’t the smallest possible permission set. It’s the right size.

Too big, too small, the right size Three columns. Too big, a whole job in one: one permission set holds a whole job, so you can't give part of it, and any difference means a copy. Too small, the Lego nightmare: dozens of tiny permission sets, so one person is built from many pieces, and nobody can say what a user can do. The right size, one task each: one task in each permission set, split only what's ever given apart, bundled into permission set groups. Footnote: small, but not too small. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.52.0", "built": "2026-10-29", "id": "DGM-SVA-SA-04", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "comparison 0.5.0", "theme": "stevetecharc 1.4.0"} Too big a whole job in one One permission set holds a whole job You can't give part of it Any difference means a copy Too small the Lego nightmare Dozens of tiny permission sets One person built from many pieces Nobody can say what a user can do The right size one task each One task in each permission set Split only what's ever given apart Bundled into permission set groups Small, but not too small. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Small, but not too small

Section titled “Small, but not too small”

Here’s the test I use. Make them small, but not too small. If two permissions are given together in every situation, splitting them is a waste: it’s two blocks that always travel as one. If you have a situation where someone needs to read something, and separately someone else needs to edit it, then split them apart.

Let me show you with Paul. Paul is a pilot at an airline that runs its operations in Salesforce. Paul needs to see the airports on each flight, and the navigational aids along the route. You could build one permission set, “Pilot access”, with both. But an airport planner on the ground needs to see the airports and has no use for the navigational aids. So you build two: View Airports and View Navigational Aids. Paul gets both. The planner gets one. Nothing is copied, and when the airports object changes, you change one permission set.

That’s the whole rule. Split only what’s ever given apart.

Paul and the planner, from the same blocks Two users and two permission sets. Paul, a pilot, has View Airports and View Navigational Aids. An airport planner, who works on the ground, has only View Airports. Footnote: split only what's ever given apart. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.52.0", "built": "2026-10-29", "id": "DGM-SVA-SA-05", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "cells 0.4.0", "theme": "stevetecharc 1.4.0"} THE USERS THE PERMISSION SETS Paul a pilot An airport planner works on the ground View Airports read the airports View Navigational Aids read the navigational aids has has has Split only what's ever given apart. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

The same blocks can build very different things. A big ship for one person, a small one for another, all from the same pieces. That’s the point of building blocks: you don’t need a new block for every new shape.

Should a permission set carry a license?

Section titled “Should a permission set carry a license?”

When you create a permission set, Salesforce asks which types of users it’s for. You can pick a specific user license or permission set license, or “if users with different licenses are assigned the permission set, select None.” If you pick a license, the permission set “can only include the permission and settings entitled by that license” (Create Permission Sets (opens in a new tab)).

My advice in class has always been: don’t tie a permission set to a license unless a permission in it requires one. A permission set with no license can be given to users with different licenses, a Salesforce user and a Platform user alike. Each user still needs a license that allows what’s in it: “the users must still be entitled to its included permissions via their user license or separately assigned permission set licenses” (same page).

To be fair to the other side, Salesforce names two reasons to tie one. First, “Permission sets associated with a user license or permission set license are more performant than those without license restrictions,” which matters when you give one permission set to many users. Second, a clone keeps the license of the permission set it came from, and you can’t change the license on a clone, so Salesforce says to “Clone a permission set only if the new one requires the same user license as the original” (Permission Set Considerations (opens in a new tab), Salesforce Help, checked 2026-11-01).

So here’s the decision. If one permission set will be given to thousands of users who all have the same license, tying it to that license is reasonable. If it’s a block you want to use across different kinds of users, leave the license off. Either way, decide it when you create it, because you can’t change it on a clone. Module 6 covers licenses.

The kinds of permission sets

Section titled “The kinds of permission sets”

Not every permission set in your org is one you made. There are four kinds worth knowing.

  • Custom permission sets. The ones you create or clone. They count toward your org’s limit.
  • Standard permission sets. These come with a feature, tied to a permission set license, such as the console user permission set for a console license. You can’t edit one, but you can clone it as often as you like. “Standard permission sets don’t count against your org’s permission set limits,” but “Clones do count against your org’s permission set limits.” To find them, add Is Custom to your list view: the box isn’t checked for a standard permission set, and Salesforce can update them when it adds a feature (Standard Permission Sets (opens in a new tab), Salesforce Help, checked 2026-11-01).
  • Permission sets from managed packages. An app you install from AppExchange can bring its own. They have their own allowance, shown below.
  • The permission set inside every profile. This one surprises people. Since API version 25.0, “every profile is automatically associated with a permission set.” It stores the profile’s user, object and field permissions. You can query it, but you can’t change it, and it isn’t visible in Setup (Permission Set Considerations (opens in a new tab)).

Two more kinds come later: session-based permission sets, which a user has but which stay off until something switches them on (module 4), and the permission set groups that bundle them (module 3).

The kinds of permission sets Four columns. Custom, you create or clone: the ones you build; they count toward the 1,000. Standard, they come with a feature: tied to a permission set license; you can't edit them; they don't count, but their clones do. From packages, an installed app's own: brought by a managed package; up to 1,500 in all, with yours. Inside every profile, one each: holds the profile's permissions; you can query it, not change it; not shown in Setup. Footnote: Enterprise Edition allocations, checked 2026-10-29. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.52.0", "built": "2026-10-29", "id": "DGM-SVA-SA-06", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "comparison 0.5.0", "theme": "stevetecharc 1.4.0"} Custom you create or clone The ones you build Count toward the 1,000 Standard come with a feature Tied to a permission set license You can't edit them Don't count; their clones do From packages an installed app's own Brought by a managed package Up to 1,500 in all, with yours Inside every profile one each Holds the profile's permissions You can query it, not change it Not shown in Setup Enterprise Edition allocations, checked 2026-10-29. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

The limits, dated

Section titled “The limits, dated”

In Enterprise Edition, Salesforce’s allocations are 1,000 permission sets you create, 1,500 counting the ones added by installed managed packages, and 800 permission set groups you create (Salesforce Enterprise Edition Allocations (opens in a new tab), Salesforce Help, checked 2026-11-01). The 1,000 is the same in Unlimited, Performance and Developer editions; Professional Edition gets 10; and it can be raised only “by upgrading your edition or by purchasing an add-on” (Increase Number of Permission Sets per Organization (opens in a new tab), Salesforce Help, published 2026-04-22, checked 2026-11-01). A permission set group can hold up to 100 permission sets (Permission Set Group Considerations (opens in a new tab), Salesforce Help, checked 2026-11-01).

Those numbers change, so check your own org’s limits before you design around them. But they tell you something. Remember the large telecom company from module 1, moving off about 200 profiles. Some people there talked about hundreds or thousands of permission sets. Thousands would be excessive and too granular, and you’d hit the limit. The limit is a hint from Salesforce about the right size.

Salesforce gives one more hint. For better performance, “we recommend assigning users permission set groups instead of many individual permission sets,” especially when many users have the same several permission sets (Permission Set Considerations (opens in a new tab)). The blocks are meant to be built into something. That’s module 3.

What an architect decides here

Section titled “What an architect decides here”
  • The size of a permission set: one task each, with permissions split only where they’re ever given apart.
  • How permission sets are named and described, so the next admin can tell what each one is for without opening it.
  • Whether each permission set carries a license, decided when it’s created.
  • Which standard permission sets to use as they are, and when a clone is worth the count.
  • Which installed packages bring their own permission sets, and who reviews what they grant.
  • How close the org is to its limits, and whether the count is growing faster than the kinds of tasks.

Beyond the exam: what AI changes. Making a permission set is about to get very easy. Salesforce’s own help now suggests asking the Setup agent: “Create a permission set named ‘Report Management’ with a description of ‘Enables user to make report changes’” (Create Permission Sets (opens in a new tab)). When a new permission set costs one sentence, the Lego nightmare arrives faster. The sizing rule doesn’t change: the agent can build the block, but you still decide what a block is.

Explore

Section titled “Explore”