Getting permissions right the first time

This one is for the practitioners - admins and consultants who have lived through a go-live where permissions were an afterthought. You'll recognise the pattern.

There is a shortcut that appears on certain Salesforce implementations, usually around the point where testing begins and someone needs to be unblocked. It sounds reasonable in the moment and is offered with good intentions. But it quietly stores up one of the most avoidable sources of pain in the entire project lifecycle.

The shortcut is this: grant testers System Administrator access so they can move faster.

The person who suggests it - sometimes a project manager on either side of the table, vendor or client - genuinely believes they are helping. They see a blocker. They have a lever, so they pull it. If the consultant is overly accommodating they might even agree to it, because it eases the friction.

But they do so without foresight of the impact it will have later.

Why it backfires

When testers operate with System Administrator rights, they can do things that end users will not be able to do in the live system. The system appears to work and defects go undetected. Permission-related bugs stay hidden because the tester's elevated access quietly leaps over them. Everything looks fine - until go-live, when real users with real permission setups encounter a system that was never actually tested for them.

At that point, features that "passed" testing begin to fail. The team scrambles to diagnose issues that shouldn't exist. Developers troubleshoot problems caused not by the solution, but by the test environment it was tested in. It is expensive, demoralising, and entirely avoidable.

There is also a second problem, which is less technical and more human. Once elevated access has been granted, rolling it back becomes difficult. End users who have been given System Administrator rights tend to hold onto them. There is an element of status involved - elevated system access confers a certain sense of importance - and there is a genuine fear that removing it will cause disruption. What was intended as a temporary shortcut quietly becomes a permanent fixture. Which brings us to a point worth calling out.

A pattern that deserves its own mention

The testing scenario is one instance of a much older and more persistent problem: live Salesforce orgs where large swaths of users - sometimes every user - has System Administrator rights in Production.

This is not a theoretical risk. It is extremely common. It happens partly through accumulated shortcuts like the one described above, and partly because self-taught administrators, understandably, find it easier to grant broad access than to diagnose and resolve specific permission gaps. The result is an org where the security model exists on paper and nowhere else, where there is no meaningful separation of responsibilities, and where a well-meaning user with no malicious intent can cause serious damage simply by having access they were never supposed to have.

If this describes your org, you already know it. The question is whether you have a plan to address it.

The right approach: design permissions upfront, deliberately

The alternative to the shortcut is not complicated, but it does require discipline and a willingness to hold the line when pressure builds.

Permissions should be designed before development begins and enforced throughout testing. That design should be grounded in a small number of clear principles. The most important one, in practical terms, is this: a permission should be governed in one place.

If the same object or field-level security permission can be granted through two or more different permission sets or profiles, it becomes ambiguous - both during implementation and later during operations. The developer doesn't know where to add access. The administrator doesn't know where to look when something breaks, or which version of the permission to assign to the user. Ambiguity in a permission model is a debt that compounds over time.

On the question of profiles versus permission sets: profiles are one-dimensional. A user has just one profile, which means every permission decision made at the profile level is a blunt instrument applied uniformly. Permission sets and permission set groups allow you to be granular - to grant specific access to specific roles without contaminating the broader security model. They make it genuinely feasible to deliver on the Principle of Least Privilege, which is the goal. Profiles still exist and still have a role, but governing system permissions through them in 2026 is working against the tool rather than with it.

CRUD (Create, Read, Update, Delete) and field-level security (FLS) should also be treated as separate concerns. Logically, they are related - you cannot have meaningful FLS access without some degree of CRUD access to the underlying object. But they should never be conflated in the permission design. A user may legitimately need object-level access without needing access to every field on that object. Building that separation in from the start is far easier than retrofitting it later.

What "upfront" actually means

Designing permissions upfront does not mean producing a theoretical document that nobody consults during the build. It means defining the permission model as a concrete, enforceable design decision - which profiles exist, which permission sets govern which access, how CRUD and FLS are separated, and who holds the authority to grant exceptions. That model then becomes the reference point against which testing is conducted.

Testers should test as end users, using the permissions that end users will have at go-live. Issues that surface during testing - and they will - are a feature, not a failure. They are exactly the kind of thing you want to discover in a sandbox rather than in Production.

When a well-meaning project member suggests giving testers admin access to unblock a sprint, the correct response is not to comply and move on. It is to explain, clearly and without drama, what that shortcut will cost downstream - and to offer the alternative, which is to diagnose and resolve the actual permission issue. That takes longer in the short term. It costs considerably less in the long term.

Permissions are rarely the most exciting part of a Salesforce implementation. They sit somewhere between "foundational" and "invisible" - nobody notices them when they work, and everybody notices them when they don't. Perhaps that is exactly why they keep getting deferred. The costs are invisible until they aren't.