Extracting Field Level Security using the batch class

Most often Salesforce admins and developers tend to spend lot of time figuring out fields level security on multiple objects and fields and such process is time consuming in nature.

The following code is an attempt to extract FLS for a given object and for profile.

Step 1: Creation of batch class with Parameterized Constructor, SOQL query can be passed as string to the constructor.

//Batch Class For creating csv from query string and create file in predefined folder
global class BAT_FSCextract implements Database.Batchable<sObject>, Database.Stateful {
    public String query;  
    global String attachmentHeader;
    global List<String> csvRowValues = new List<String>();

    global BAT_FSCextract (String query){
        this.query = query;

    global Database.QueryLocator start(Database.BatchableContext BC){
        return Database.getQueryLocator(query);
    global void execute(Database.BatchableContext BC, List<sObject> scope){
        //Retrieved Records from the FieldPermissions (order: Name, Sobject Type, PermissionsRead, PermissionsEdit)
        for(FieldPermissions  currFieldPermissions : (List<FieldPermissions >) scope){
            String Field = currFieldPermissions.Field;
            String SObjectType = currFieldPermissions.SObjectType;
            Boolean PermissionsRead = currFieldPermissions.PermissionsRead;
            Boolean PermissionsEdit  = currFieldPermissions.PermissionsEdit;
            String rowStr = Field + ',' + SObjectType + ',' + PermissionsRead + ',' + PermissionsEdit;
    global void finish(Database.BatchableContext BC){
        List<Folder> folders = [SELECT Id, Name FROM Folder WHERE Name = 'FSC_log'];
            String documentName = 'FieldLevel Security-'+ Datetime.now().format('MMM') + Datetime.now().year();
            attachmentHeader = 'FieldName, Object Name, Read, Edit\n';
            String csvFile = attachmentHeader + String.join(csvRowValues,'\n');
            // Insert the generated CSV file in Document object under "Setup Audit Trail Logs".
            Document doc = new Document(Name = documentName, Body = Blob.valueOf(csvFile), FolderId = folders[0].Id, Type = 'csv', ContentType='application/vnd.ms-excel');
            insert doc;

Step 2. Construct SOQL query for the given profile and object, in this case it is System Admin profile and the Account object.

//String to be used in query
String queryToPass ='SELECT Field, SObjectType, PermissionsRead, PermissionsEdit FROM FieldPermissions WHERE parentId IN ( SELECT id FROM permissionset WHERE PermissionSet.Profile.Name = 'System Administrator' AND IsOwnedByProfile = true) AND SObjectType = 'Account' ORDER BY Field ASC';

Step 3. Execute the batch from any possible way, here code block is executed from anonymous execution block

//Call the batch
Id batchJobId = Database.executeBatch(new BAT_FSCextract(queryTopass));

There can be multiple extension this solution, for example ….
1. Run on schedule based or create UI elements to allow business users/sys admins to get ad hoc reports for FLS.
2. Schedule this every day and create deltas using server side applications.
which can look into the excel/csv files.
3. Merge files for different Objects and Different Profiles, same as use case mentioned in https://www.bofc.io/ app exchange application but it needs considerable amount of efforts to get there.

Triggers and Order of Execution

Before Salesforce executes on event on the server, the client browser runs JavaScript validation check.

On the server, Salesforce:

  1. Loads the original record from the database or initializes the record for an upsert statement.
  2. Loads the new record field values from the request and overwrites the old values.

    If the request came from a standard UI edit page, Salesforce runs system validation to check the record for:

    • Compliance with layout-specific rules
    • Required values at the layout level and field-definition level
    • Valid field formats
    • Maximum field length

    When the request comes from other sources, such as an Apex application or a SOAP API call, Salesforce validates only the foreign keys. Prior to executing a trigger, Salesforce verifies that any custom foreign keys do not refer to the object itself.

    Salesforce runs user-defined validation rules if multiline items were created, such as quote line items and opportunity line items.

  3. Executes all before triggers.
  4. Runs most system validation steps again, such as verifying that all required fields have a non-null value, and runs any user-defined validation rules. The only system validation that Salesforce doesn’t run a second time (when the request comes from a standard UI edit page) is the enforcement of layout-specific rules.
  5. Executes duplicate rules. If the duplicate rule identifies the record as a duplicate and uses the block action, the record is not saved and no further steps, such as after triggers and workflow rules, are taken.
  6. Saves the record to the database, but doesn’t commit yet.
  7. Executes all after triggers.
  8. Executes assignment rules.
  9. Executes auto-response rules.
  10. Executes workflow rules.
  11. If there are workflow field updates, updates the record again.
  12. If the record was updated with workflow field updates, fires before update triggers and after update triggers one more time (and only one more time), in addition to standard validations. Custom validation rules, duplicate rules, and escalation rules are not run again.
  13. Executes processes.

    If there are workflow flow triggers, executes the flows.

    The Process Builder has superseded flow trigger workflow actions, formerly available in a pilot program. Organizations that are using flow trigger workflow actions can continue to create and edit them, but flow trigger workflow actions aren’t available for new organizations.

  14. Executes escalation rules.
  15. Executes entitlement rules.
  16. If the record contains a roll-up summary field or is part of a cross-object workflow, performs calculations and updates the roll-up summary field in the parent record. Parent record goes through save procedure.
  17. If the parent record is updated, and a grandparent record contains a roll-up summary field or is part of a cross-object workflow, performs calculations and updates the roll-up summary field in the grandparent record. Grandparent record goes through save procedure.
  18. Executes Criteria Based Sharing evaluation.
  19. Commits all DML operations to the database.
  20. Executes post-commit logic, such as sending email.