On a recent deployment of our package to a newly spun up Enterprise org I received an error whilst logged in as system admin around insufficient permissions: "Insufficient Permissions: secure query included inaccessible field". In the end it was the Account.TickerSymbol that was the issue.

My question is: why does the System Admin profile not get access to all standard objects and fields? I could understand if another profile didn't have access but assumed Sys Admin had access to the kitchen sink (especially on a common object like Account).

I've worked around it with permission sets but was curious as to the "why" behind the initial issue.

2 Answers 2


Administrators do, by default, get access to all standard fields on all standard objects. There's a number of reasons why this field might not have had visibility for administrators. For example, removing a field from a page layout in Professional Edition used to also turn off field level security, as they didn't have custom profiles. If you later upgraded to Enterprise Edition, that Field Level Access would still have been turned off.

Or, maybe an administrator figured nobody was using the field, so just disabled it for everyone, to clean up reports, layouts, and list views. Or maybe it was an accident, and didn't realize what they were doing for some reason.

There are plenty of legitimate reasons why you might want to turn off field access, even for administrators. And administrators can generally do whatever they want, even potentially doing things that could remove their ability to log in!

And, because of how the security policies are at salesforce.com, there can be quite a bit of red tape involved fixing these sorts of problems. Administrators do have the authority to do pretty much whatever they want to do, even some things that would be really bad.

If the change was done in the last six months, the Setup Audit Trail should show who removed the field access, and when, but aside from that, all we really have is speculation. Someone, somehow, decided to disable this field, for the administrator profile.

Even though System Administrators can do pretty much anything, they can also restrict themselves from doing things as well; the only real restrictions in place on administrators is that they cannot revoke their own administrator permission (e.g. they cannot make themselves a Standard User, or deactivate their own user profile).

  • Thanks for your answer, @sfdxfox. In my case it was a freshly spun up Enterprise org so no other users could have gotten into it, but your answer may have spurred me on to why it's happening for me. In our PBO there is no access to this field on Sys Admin and I'm guessing this profile is inherited in orgs spun up from the PBO. It still raises the point though that all standard fields required by a package should be defined in permission sets by the package to ensure people messing with profiles doesn't break anything. Cheers for your help!
    – Shane Bird
    Commented Aug 6, 2021 at 12:56
  • On further investigation changing the profile in the PBO made no difference. What did seem to make a difference was the type of org it was, with Enterprise not having access to TickerSymbol (and other fields) in the Sys Admin profile whereas other orgs like Dev Edition did have access.
    – Shane Bird
    Commented Aug 6, 2021 at 14:01
  • @ShaneBird Might just be the way the templates for those orgs are set up. I wouldn't imagine that TickerSymbol would have been excluded by default. That's interesting.
    – sfdcfox
    Commented Aug 6, 2021 at 14:30
  • I definitely agree that it's interesting. Still haven't been able to find much rhyme or reason as to why. Maybe it's just a miss on SF's behalf.
    – Shane Bird
    Commented Aug 13, 2021 at 16:30

In addition to @sfdcfox answer, I have noticed that Admin profile doesn't always get read/edit FLS on standard fields when either of these events occur

  • A feature is enabled (in my case, it was Orders)
  • A new release of SFDC for a standard object with new fields that in turn is gated by having to enable the feature/capability in the UX

Now, I'll admit this experience is from a few releases back and SFDC may have fixed my specific use case. But I agree, it is certainly weird for Admin to not have FLS on standard object fields.

  • Cheers for this @cropredy, it's nice to know it's not just our company experiencing it. Maybe it will be fixed in a future release but tough to know. Did you raise it with SF or was it just fixed over time by them?
    – Shane Bird
    Commented Aug 13, 2021 at 16:31
  • I did not raise it at the time - I just went "aargh" and changed FLS and got on with my day
    – cropredy
    Commented Aug 13, 2021 at 17:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .