Field Level Security (FLS) is a great feature which allows you to lock down certain fields to specific users or teams. You can control who can read the data, create the data and edit the data. This allows administrators to account for many security needs. For more detailed information on Field Level Security review this TechNet documentation.
It is also a good idea to use solutions when moving customizations and this includes customizations to your security model and security settings. These are areas that can greatly impact users so they always should be tested in a development environment if possible.
Here are some things to keep in mind when moving Field Level Security Profiles between environments:
- The field must have FLS enabled before the FLS Profile can be updated. This means your release process must be a 2 step process: (1) Import a solution containing the field and publish, then (2) Import a solution containing the FLS profile and publish. If all is contained in one solution you will get a warning on the FLS profile but not an error. Then all permissions for the field (with FLS freshly enabled) will be set to No. This means that only Administrators can view and edit the field.
- When creating a new FLS profile, members must be added in each environment. The linked teams and users are not included in the solution and must be added manually.
- Test thoroughly in each environment. Remember Administrators will always have access to any field with FLS enabled so other users need to be involved in testing. If one users is doing the testing for multiple roles, double check your changes and have them clear their cache between test cases. This will ensure any issues from items 1 and 2 do not occur.
How have you used Field Level Security? Any other tips for Administrators to keep in mind?