FLS (Field-Level Security) Errors After Package Upgrade to R36 MR2 or Later

Symptom

After upgrading CloudSense packages to R36 MR2 or a later release (R36 MR3, R37, R38), users get Field-Level Security (FLS) errors in operations that worked before the upgrade, for example when they select products, save product configurations, activate orders or run CloudSense processes. The error has this form:

FLS Exception --- UpdateChecker, Object failed: [Object_Name], field not Updateable: [Field_Name]

The same error can also show InsertChecker with "field not Createable", or SelectChecker with "field not Accessible".

The errors usually affect users who do not have the CloudSense permission sets: read-only, analytics and integration users, and users with custom profiles or permission sets. Apex tests that create CloudSense data inside System.runAs with such a user fail with the same error. System Administrators are usually not affected. Orgs that are not yet upgraded do not show the errors.

Cause

CloudSense packages read and write their data through common methods in the CloudSense Utilities package (csutil). These methods can check the field-level security of the running user before each operation (the "enhanced FLS checks"). The checks are part of the Salesforce security review requirements for managed packages.

Utilities v37.0, released with R36 MR2 (February 2024), switched these checks on by default (T-63944, listed in the Utilities R36 MR2 Release Notes). Utilities R36 MR1 (v36.4) and its patches have the checks off by default. All later Utilities builds, including all R36 MR3, R37 and R38 builds, have them on.

Thus every org that upgrades from R36 MR1 or earlier to R36 MR2 or later gets this change. This includes orgs that upgrade directly from R36 MR1 to R37. After the upgrade, a user must have field access to each CloudSense field that the packages read or write for that user. This includes fields that the packages update automatically, for example cscfga__Product_Basket__c.cscfga__pricing_status__c, which Configurator updates each time a product configuration is saved. Usually these fields are not new: before the upgrade, the packages wrote them without checking the access of the user.

The fields that each user needs depend on the CloudSense features and custom objects that your implementation uses. Thus there is no single list of fields for all customers.

Resolution

Option 1: Grant field access (recommended; required for production)

1. Assign the CloudSense managed permission sets to each user who works with CloudSense records, including integration and analytics users:
   • Configurator Sales User - Standard License or Configurator Sales User - No License
   • Configurator Design Time User (for users who maintain the product catalogue)
   • CS Utilities User
   Go to Setup > Users > Permission Sets, open the permission set, click Manage Assignments, then click Add Assignment.
2. If your org gives access through its own permission sets or profiles, use the managed permission sets of the installed package version as the reference. Add the field permissions that your own permission sets do not have. Compare them again after each package upgrade, because the managed permission sets are updated with the packages.
3. To correct one error: the error message identifies the object and the field. For "not Updateable" or "not Createable", give Edit access to the field. For "not Accessible", give Read access. Make the change in the permission set or profile of the affected user.

Option 2: Opt out of enhanced FLS checks (temporary workaround)

To unblock users while you complete Option 1, you can switch off the enhanced checks for the whole org. Create the JSON setting security/enableEnhancedChecks with the value false. Use one of these two methods.

Method A: Custom Setting record

1. In Salesforce, go to Setup > Custom Settings.
2. Find JSON settings (csutil__JSON_Settings__c).
3. Click Manage, then click New.
4. Set Name to security/enableEnhancedChecks.
5. Set JSON Configuration to false.
6. Click Save.

Method B: Custom Metadata record (use this method if your Apex tests are affected)

1. In Salesforce, go to Setup > Custom Metadata Types.
2. Next to Json Metadata, click Manage Records, then click New.
3. Set Label to security/enableEnhancedChecks and Json Metadata Name to security_enableEnhancedChecks.
4. Set Name to security/enableEnhancedChecks.
5. Set JSON Configuration to false.
6. Select Active.
7. Click Save.

Notes:

• Apex tests cannot see Custom Setting records unless the test uses SeeAllData=true. Thus Method A does not change the result of Apex tests. Apex tests can see Custom Metadata records, and you can deploy the record with your other metadata.
• Use only one method. If both records exist and they have different values, it is not defined which value applies.
• The value must be exactly false. If the value is not valid, the checks stay on.

Limitations of the opt-out

• The opt-out applies to the whole org and to all CloudSense packages that use the Utilities checks. It reduces the security of your org. Use it only as a temporary workaround.
• On R38, the Configurator package also checks read access with native Salesforce user-mode queries. The opt-out does not switch off these checks. On R38, a user who does not have read access to the fields that Configurator queries gets a "Security error" even when the opt-out is active. Complete Option 1 before you upgrade to R38.

Verify

Log in as an affected user (or run the failed Apex tests again) and do the operation that failed. Make sure that there is no FLS error.

Related Information

• Affected releases: R36 MR2 and later (including R36 MR3, R37 and R38) when you upgrade from R36 MR1 or earlier
• Source of the change: Utilities R36 MR2 Release Notes, T-63944 "Switch the default FLS check setting to true"
• Field Level Security Error After R37 Package Upgrade
• Salesforce documentation: Field-Level Security