Does it really matter how many users in your Salesforce org have administrative permissions? Are there risks associated with having too many Salesforce Admins? If so, how can we mitigate those risks?
The short answer is a resounding “yes.” There is such a thing as too many Salesforce Admins and the risk you’re taking by not limiting access shouldn’t be ignored. We’ll answer these questions in more depth throughout this blog as well as introduce and discuss what a tiered Admin structure is.
In this post, we also cover:
- Problems that can arise when an org has too many Salesforce Administrators
- Why enterprises should have a Salesforce Admin policy
- Who should be granted Admin permissions
- What your organization needs to cover in its Admin policy
Why Enterprise Organizations Need a Salesforce Admin Policy
When we audit a Salesforce org, it’s not unusual to find far too many Admins. This is prevalent in orgs of all sizes – from those with hundreds of users to those with several thousand. You are not alone.
For clarification, we define Admins as users with the ability to:
- Create or update Users, Permission Sets, Roles or Profiles
- Modify All records
- Export All data from Salesforce, and
- Provide access to third party integrations (that can access to Salesforce data).
Oftentimes, this is data an organization would never intentionally put in so many hands, but they don’t realize the power that Salesforce Admin permissions provide.
Accidental Admins, Ghost Admins & Integration Admins
In previous posts, we have defined Accidental Admins and Ghost Admins which are both important to understand in connection with how they impact Org security.
Often Accidental Admins are not trained, so they don’t understand how the changes they make in Salesforce impact the org as a whole. Ghost Admins on the other hand, don’t have a variation of the Standard Admin Profile, but through another Profile and/or Permissions have much of the same access and ability to impact a Salesforce Org as a full Admin Profile User. For more information, we encourage you to read the blog posts above.
What’s even more problematic, is many orgs inadvertently give third-party vendors full Admin privileges, which is not best practice. No matter how trusted the partner, an outside company should never be allowed to delete users or buy licenses in other Salesforce solutions on your organization’s behalf; which Admin Profile Users can. (For more information, click HERE).
In short, the more people and products you have with Salesforce Admins permissions, the more liability you’re introducing into your org. Luckily, you can address this issue by instituting an Admin policy at your organization that outlines who is granted various levels of Salesforce access and how such determinations are made.
..the more people and products you have with Salesforce Admins permissions, the more liability you’re introducing into your org.
Who Should Receive Salesforce Admin Access?
At CloudKettle, we advocate that you have a tiered Administrator structure. With such a structure, you’ll have a very small number of full System Admins. It’s not uncommon for us to find 20+ people with that full System Admin access, that’s far too many.
In a tiered administrator structure there are three tiers: C-Suite, Technical Admins, and Minimal Access Admins. Let’s take a closer look at how a tiered administrator structure works and each tier.
In a tiered administrator structure there are three tiers: C-Suite, Technical Admins, and Minimal Access Admins.
Tier 1: “God Power” Admins
Admins with “God Power” in Salesforce are those with full system access. Keep in mind that they can purchase things, on your behalf, inside of Salesforce. They can also enable features in the org that you may not want enabled, and they can lock people out of the org or turn it off completely.
We recommend you limit the number of Admins in the first tier, “God Power” Admins, to three employees. However, this will depend on the security and compliance framework your organization has in place and the size of your organization.
Directors and C-Level Employees
One of your “God Power” Admins should be a director or C-level employee at your organization, for example, a CFO, CIO, or CTO. For legal reasons, you often need somebody at that level to have such access, but they should never actually do anything with their access. In fact, they should be educated to not do anything.
One of your “God Power” Admins should be a director or C-level employee at your organization.
What we usually advise organizations to do is give that person two licenses–both of which will need to be paid for separately. This way they can log into Salesforce with the restricted license and maintain the “God Power” license to fulfill legal obligations in the unlikely case they actually need it.
Certified Salesforce Administrators
Aside from director or C-level employees with full system access, we recommend all “God Power” Admins be fully trained Salesforce administrators.
By fully trained, we mean these Admins should have, at minimum, a Salesforce Admin or Salesforce Developer I certification, and ideally a Salesforce Developer II or Salesforce Consultant certification.
In order to gain full “God Power,” your administrators need to have a very significant depth of knowledge in Salesforce.
Removing Full System Access from Users
What if someone in your org has “God Power” permissions and they don’t understand why they’re being asked to give them up?
Remember, people with full system Admin access have a lot of power. If they’re compromised in a phishing attack, for instance, the attacker can gain access to your org and wreak havoc. We tend to stress that worst case scenario to individuals who are hesitant to relinquish privileges because, usually, they don’t want to carry that responsibility.
So, you can see why it’s important to minimize the number of people that have “God Power” access. Let’s move onto the second tier.
Tier 2: Technical Admins
We call Administrators one level down from full access Admins “Technical Admins.” Technical Admins are set up in Salesforce as custom profiles that have many of the same powers as full System Admins, but they don’t have billing privileges. Technical Admins can’t upgrade or downgrade your licenses, either.
However, they still have broad access to the setup panel and can do just about anything. There should only be a few people with access at the Technical Admin level and they should be used strictly as technical resources.
The proxy we use to determine who gets the technical Admin level of access is similar to determining Tier 1 privileges. With the exception of the legal requirement to provide full access to a C-suite individual, nobody should get either Tier 1- or Tier 2-level Admin access without carrying at least their Salesforce Admin certification.
…nobody should get either Tier 1- or Tier 2-level Admin access without carrying at least their Salesforce Admin certification.
Additionally, your company’s Admin policy should help guide these decisions, which we’ll get into shortly.
Tier 3: Minimal Access Admins
Our third and final tier provides users within a Salesforce org limited permissions that allow them to do specific, defined actions. We call these “minimal access Admins.” As an example, you may have people in HR who need to add and remove users.
Other minimal access Admins might include people in the Marketing department or on your Business Intelligence team who can mass export data because they need to use that data for relevant projects (lead lists etc.).
Our third and final tier provides users within a Salesforce org limited permissions that allow them to do specific, defined actions.
Minimal access Admins don’t have the ability to create new fields, push code into production, change validation rules, and so on. Again, the ramifications of loosely assigning higher levels of administrative privileges could be very serious.
What to Include in Your Admin Policy
We always advise enterprise organizations to have a written Salesforce admin policy with several sections. Those sections might cover things like:
- Purpose
- Scope
- Who it applies to
- Administration of the policy
- How updates to the policy are made
- The policy itself
- How to request an exception to the policy
- All approved exceptions to the policy
Without a policy in place, the potential liability for your organization is significant. It’s too dangerous to have numerous Salesforce administrators who aren’t trained and don’t fully understand the impact of their actions within Salesforce.
Consider the consequences of GDPR violations, for instance, and whether you’re willing to give anyone who isn’t fully trained the power to export all your Salesforce org data.
Having an Admin policy in place also eliminates a lot of the politics around determining who does and doesn’t get Admin access.
Having an Admin policy in place also eliminates a lot of the politics around determining who does and doesn’t get “God Power” or Technical Admin access. If someone wants that level of access, you can point them to the section of the policy stating that Admins need to be Salesforce certified, which takes about two months and 80 hours of studying.
Salesforce certifications are not easy to get, so this–along with other sections of the policy–deters a lot of people from pursuing Admin privileges and helps reduce liabilities in your organization.
Wrap Up
If you think your organization may have too many Salesforce Admins, or you’re not sure how access levels are determined and granted within your org, we recommend an audit. Too many Salesforce Admins can increase security risks and liabilities. The next step is following a tiered approach to assigning Salesforce permissions and, finally, instituting a written Admin policy.
We hope you find the actionable insights provided here to be helpful. Have questions about Salesforce security? Sign up for our newsletter! We send out a monthly recap of our latest Salesforce content, including articles on security best practices, actionable insight on Salesforce optimization for enterprises, and more.
