Skip to content
Home » Blog » Accidental Permissions

Accidental Permissions

Blowing the “Single Profile” approach out of the water

When you install a package from AppExchange via the browser you get to choose whether to Install it for All Users, Only Admins, Specific Profiles or no-one. This really means if you want to grant full access to Classes, Pages, Fields (and more) to your users. See here for more details of exactly what users get granted access to. You can install any package this way so long as you know the Package Version Id (the “04t” Id).

If you want to install or upgrade a package via the Salesforce CLI e.g. in automated pipelines like GitHub Workflows (which you always do in any sort of bigger project) you only have 2 of the choices available to you in the equivalent --security-type parameter: AllUsers or AdminsOnly. Notice the lack of a “NoAccess” option.

We have been very good in our project and all our permissions (and I mean all) are done via Permission Sets organised into Permission Set Groups. We only have a single profile for everyone, users are provisioned via API and we have some automation to pick the right Permission Set Groups. Beautiful solution. 

Ok, Page Layout assignments or Flexi page assignments. But they are not really permissions.

Until we found the supposedly empty profile full of permissions no-one had set on it. That’s when we realised this sentence in the documentation is not 100% accurate:

Install for Admins Only

Specifies the following settings on the installing administrator’s profile and any profile with the Customize Application permission.

What it really should say is “Specifies the following settings on the installing user’s profile and any profile with the Customize Application permission“. Our user had the Customize Application permission, but via a Permission Set. 

The only solution to this is having a different profile for the “deployment user” and accept that they will have many unintended permissions. Or clean it up after every upgrade.

Salesforce say (via Support) that the CLI is intended to automate deployment of metadata changes. It is not intended to manage permissions (yet). I’d say that the lack of a “NoAccess” option is actually having quite the effect on your permission management. Both “No profile” and “Package delivery” are examples of best practices IMO, but you have to muddy them a bit to use both at the same time. 

Other Traps

UoW and SObject Instances

Oct 28, 202314 min read

I previously talked about the need to be careful about how you register records as dirty with the Apex Common’s Unit of Work. There is another little gotcha to be ware of I recently ran into. Though when it does happen to you then you are probably doing something you…

Wasting Time in Disabled fflib Trigger Handlers

Jun 27, 202304 min read

Did you know that you can dynamically disable fflib_SObjectDomain Trigger Handlers? You did? Ok then, did you know that when you do disable them their constructors run anyway? So be careful not to put any (expensive) logic inside those. For instance, I had some common related records that needed to…

0 0 votes
Article Rating
Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x