Find your content:

Search form

You are here

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?

Attribution to: jkraybill

Possible Suggestion/Solution #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)

Attribution to: metadaddy
This content is remixed from stackoverflow or stackexchange. Please visit

My Block Status

My Block Content