4

I'm working on creating a managed package and am struggling to understand the permission model. The managed package will be accessed by a Sales Manager kind of profile and needs access to few custom objects present in the package. I have permission sets which assign permissions to all objects and fields.

I have the following questions:

  • Should I be providing permission to the System admin for all fields/objects? Or the System admin can assign the permission set to itself after install?

  • Will the system admin use the permission set to assign permissions to users?

  • Does the system admin need access to all custom objects and fields in the managed package? Or I can have objects which are not accessible by the System admin? If yes, how would the apex code (which runs in system mode) access these variables? If not, Is the assumption that system admin indeed needs access to all custom objects/fields, correct?

1 Answer 1

3

Should I be providing permission to the System admin for all fields/objects? Or the System admin can assign the permission set to itself after install?

System Administrator has Modify All Data, and the system also automatically gives them permission to all components on install. There's generally no need for a System Administrator to assign permissions to themselves.

Will the system admin use the permission set to assign permissions to users?

That is the recommended approach. Create Permission Sets that identify roles within your app/package, so that your admins can provide appropriate permissions to their users.

Does the system admin need access to all custom objects and fields in the managed package? Or I can have objects which are not accessible by the System admin?

Admins must have access to all normal objects. They are, after all, admins. However, you can use a Protected Custom Setting to prevent even admins from seeing certain protected values, like passwords, private keys, etc. There's limited storage for custom settings, but ideal for storing private data.

If yes, how would the apex code (which runs in system mode) access these variables? If not, Is the assumption that system admin indeed needs access to all custom objects/fields, correct?

Only Apex Code inside your package can access and update the values in Protected Custom Settings. This is enforced by the platform. There is no way for the admin to ever see or modify the values stored here. Apex Code in generally can access any normal object, but Protected Custom Settings are protected by the compiler and runtime.

3
  • Thanks for your detailed response. You mentioned "Admins must have access to all normal objects" - here by normal do you mean only standard objects or custom objects as well? I understand we can keep custom settings protected. But does it make sense to protect custom objects from admin as well?
    – zanzi
    Mar 17, 2017 at 4:42
  • Also, do I need to add a sys admin profile to my package or should the permission set explicitly have to contain permissions for a system admin? For eg. When creating a field in a custom object, we have to set the FLS. If I do not select any profile for FLS, does it mean even system admin wont have access to it? Would the managed package apex code be able to access this field?
    – zanzi
    Mar 17, 2017 at 4:46
  • @zanzi Custom objects can't be protected the same way custom settings can. You don't need to add a profile to your package, as the install wizard will take care of the FLS for you. Apex Code runs in system context, so it can always access all fields and objects in your package.
    – sfdcfox
    Mar 17, 2017 at 12:30

You must log in to answer this question.

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