Any docs on the permissions of the special InstallHandler package user?

InstallHandler is the interface you implement for a post-install script in a managed package. Per the docs:

It runs as a special system user that represents your package, so all operations performed by the script appear to be done by your package. You can access this user by using UserInfo.

I just added some functionality to a previously working install script to populate a new custom field the package installs against Lead, but unexpectedly got

System.QueryException: sObject type 'Lead' is not supported.

when it ran as part of the InstallHandler. When the same code is executed in the target org by a normal user it runs fine.

I’m theorizing that this “special system user” has a limited set of permissions, and although I’ve worked around it for now I’d like to know what other limitation it has so I can avoid them. I can’t find any docs on this though. Anyone know more than what’s on the docs page above?


Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.

Method 1

No docs, but zachelrath has written an awesome blog post on the subject of install scripts: Migrate your post-install and uninstall tasks to Apex Install Scripts. I’m pasting the relevant info below, but go read the whole post!

In the absence of documentation, the only way to find out was to
either ask questions of the SFDC community, or find out through
experimentation. I did both, and here are some things I discovered:

  • Install Scripts execute as a totally unique User and Profile
    • Neither the User nor Profile exist in either Source or Destination orgs.
    • This User / Profile has essentially ‘God’ / System privileges
    • This User / Profile can create / modify records of Standard objects as well as Custom Objects / Custom Settings that come with the package being installed.
  • DML operations fail if they are not initiated from the class which implements the InstallHandler interface
    • A DML operation executed from a helper class will fail due to SObjectExceptions such as “Field Name is not accessible”
    • Simply extracting this code back in to the class which implements InstallHandler can avoid this issue
  • Schema Describe Information on Object or Field Accessibility always returns FALSE
    • Calls such as Contact.Name.getDescribe().isAccessible() will universally return FALSE regardless of Profile permissions in either Source or Destination org
    • Consequences: Do NOT try to dynamically determine whether to permit DML based on permissions from within Install Scripts. You will get very frustrated.
    • Timeline for Resolution: Spring 13 release (Safe Harbor — got this from SFDC support)

All methods was sourced from or, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0

0 0 votes
Article Rating
Notify of

Inline Feedbacks
View all comments
Would love your thoughts, please comment.x