+ Start a Discussion

How to include Field Level Security in a package?

I've created a managed package with a custom field (on User) and I want that, when an organization installs the package, all users have access to this custom field (more precisely, I want this custom field to be queriable through the API).


For now I ask the admin of each organization to set the Field Level Security for this field to "Visible" for all profiles, but it's too much work for me (and them).


I guess that a solution would be to include FLS for this field in the package. This question was handled in this thread but JonP's answer did not work for me.


I tried the solution described by JonP. I've added a custom profile with the right FLS for this field in my package (I've built the package in a Developper Edition), then I've installed it in a Enterprise Edition TestOrg, but the wizard did not appear. Furthermore when I look to the content of the package, on publisher side, there is a line for my custom profile with the following data:

  Type: Profile Settings

  Included By: User Selected

  Available in Versions: N/A

I guess the last point (N/A) may be a problem but I am not sure as, in the third message of this thread, "chess" had the same properties for its package but he apparently saw the wizard (although he was confused about the expected behaviour).


So my questions would be:

  • Is JonP answer outdated?
  • If not, can someone be more specific about what should be done in the package to make this wizard appear?
  • More generally speaking, is there any another way to ensure that, by default, all users have access to a custom field included in a package?

Other related thread : http://boards.developerforce.com/t5/Apex-Code-Development/Bundle-user-profile-in-managed-package/td-p/191786



* I think it has to be a managed package for that wizard to appear, but I've not seen it yet. A "better" idea would be to create a Permission Set, which you can then assign to all users as need be.

* When I find this wizard, I'll let you know.

* No, that's the point of the install wizard. Admins have to choose what is available per user.


> A "better" idea would be to create a Permission Set, which you can then assign to all users as need be.


Thank you for this quick answer, I didn't think about this feature.


That sounds promising as a Permission Set can be included in a package, and Permission Sets included in a package are supposed to be available even in Group and Profesional Edition.


However, when I try to use Permission Set, I am not sure I understand how it can help me.


If I include permission set in the package, instead of asking the admin of each organization to set the Field Level Security for this field to "Visible" for all profiles, I will have to ask the admin of each organization to assign the permission set to each users, which seems to be even more work. It would have been less work only if I had more than one custom field and if there was a possibility to mass-assign a permission set to many users (which does not seem the case).


I did not find an option, when I built the permission set or when I included it in the package, to say that this permission set should be automatically assigned to everyone on the installation.


In my first message, I did not say clearly enough why I was interested in the inclusion of a profile. In this case, the Wizard is supposed to appear during the installation. So even if the admins of each organization still have to do something (that would be to map the package profile on every profile - not sure about what it implies, I would have to check that anyway) but, at least, they can not forget that there is something to do. I won't have to call them one by one after each installation to ensure they will do an extra step (setting the FLS for every profile).


This sounds like a small detail but most of the installations of our package have problems because of this extra step that is rarely done.



> Admins have to choose what is available per user.


I think I understand the idea but as the package I'm talking about is managed by LMA, admins can already choose if the content of the package (including the custom field we talk about) is available for each user. So basically, with FLS, they have to do it twice...



Salesforce really does take FLS out of the hands of the developer and puts it into the hands of the administrator.


At this point, it might almost be easiest to just use the new Summer '12 functionality to create an install script that creates a Task for each sysadmin, or at least the user installing the package, to set the FLS.