Start a conversation Sign in
Start a conversation
  1. CloudSense Support
  2. CloudSense Articles
  3. Articles

Field Level Security Error After R37 Package Upgrade

Problem

After upgrading CloudSense packages to Release 37 (R37), users encounter Field Level Security (FLS) errors when performing standard CloudSense operations such as:

  • Creating or editing product configurations
  • Activating orders
  • Updating subscriptions
  • Running CloudSense processes

The error message typically appears as:

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".

These errors prevent users from completing their work and may block critical business processes. Apex tests that create CloudSense data inside System.runAs with a restricted user can fail with the same error.

Root Cause

CloudSense packages read and write their data through common methods in the CloudSense Utilities package (csutil). These methods check the field-level security of the running user before each operation (the "enhanced FLS checks"). Utilities v37.0, released with R36 MR2, switched these checks on by default (T-63944). All R37 Utilities builds have them on.

Thus, if your org upgrades from R36 MR1 or earlier directly to R37, the checks are switched on together with the R37 upgrade. Usually the fields in the errors are not new: before the upgrade, the packages wrote them without checking the access of the user. Now each user must have access to each CloudSense field that the packages read or write for that user.

Common scenarios include:

  • Users without the CloudSense permission sets (for example read-only, analytics or integration users) who save product configurations
  • Custom profiles or permission sets that do not give Edit access to 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
  • Apex tests that create CloudSense data with System.runAs and a restricted profile

For the full background and a temporary opt-out, see FLS (Field-Level Security) Errors After Package Upgrade to R36 MR2 or Later.

Resolution

Step 1: Identify the Affected Field and Object

  1. Review the full error message to identify:
    • The object name (e.g., cscfga__Product_Basket__c)
    • The field name (e.g., cscfga__pricing_status__c)
    • The operation that failed: SelectChecker (read), InsertChecker (create) or UpdateChecker (update)
  2. Note the user profile and permission sets of the affected user.

Step 2: Review Field Level Security Settings

  1. Navigate to Setup > Object Manager
  2. Search for and select the object identified in Step 1
  3. Click Fields & Relationships
  4. Locate the field identified in Step 1
  5. Click on the field name
  6. Click Set Field-Level Security
  7. Review which profiles have Visible and Read-Only access

Step 3: Grant Appropriate Field Access

  1. On the Set Field-Level Security page, find the profiles of the affected users.
  2. For each profile, select Visible.
  3. If the error is "not Updateable" or "not Createable", make sure that Read-Only is not selected.
  4. Click Save.

Alternative Method (Profile or Permission Set):

  1. Navigate to Setup > Users > Profiles (or Permission Sets)
  2. Select the profile or permission set used by the affected user
  3. Click Object Settings
  4. Select the object identified in Step 1
  5. Click Edit
  6. Locate the field in the Field Permissions section
  7. Select Read Access and Edit Access as appropriate
  8. Click Save

CloudSense provides managed permission sets that give the field access that the packages need. Assigning these permission sets is the most reliable way to ensure proper field access, because they are updated together with the packages:

  1. Navigate to Setup > Users > Permission Sets
  2. Locate the CloudSense permission sets:
    • Configurator Sales User - Standard License or Configurator Sales User - No License (users who create or edit product configurations)
    • Configurator Design Time User (users who maintain the product catalogue)
    • CS Utilities User (Utilities)
  3. Open the appropriate permission set
  4. Click Manage Assignments
  5. Click Add Assignment
  6. Select the affected users
  7. Click Assign

If your org gives access through its own permission sets, use the managed permission sets of the installed package version as the reference, and add the field permissions that your permission sets do not have.

Step 5: Verify the Fix

  1. Log in as the affected user (or ask them to test)
  2. Retry the operation that previously failed
  3. Verify the FLS error no longer appears
  4. Confirm the operation completes successfully

Step 6: Apply to All Affected Users

  1. Identify all user profiles that may be affected by the same FLS issue, including integration and analytics users
  2. Repeat Steps 3-4 for each profile or permission set
  3. Notify users that the issue has been resolved

Prevention

For Salesforce Administrators

  • Pre-Upgrade Review: If you upgrade from R36 MR1 or earlier, read the Utilities R36 MR2 Release Notes (T-63944) as well as the R37 release notes, and plan field access for all users who are not administrators
  • Permission Set Strategy: Use CloudSense-provided permission sets, or compare your own permission sets with them after each upgrade
  • Testing: Test all critical CloudSense operations and run your Apex tests in a sandbox with representative user profiles before deploying upgrades to production
  • Documentation: Maintain a list of custom profiles and their required FLS settings for CloudSense objects

For Implementation Teams

  • Pre-Upgrade Planning: Before upgrading CloudSense packages, plan the field access for each user persona, including integration and analytics users
  • Automated FLS Deployment: Use change sets or metadata API to deploy FLS settings consistently across environments
  • User Communication: Notify users of potential FLS issues after upgrades and provide a clear escalation path
  • Affected Release: CloudSense R37 and later (and R36 MR2 or later), when you upgrade from R36 MR1 or earlier
  • Affected Objects: All CloudSense managed objects (varies by package and implementation)
  • Cause: Utilities enhanced FLS checks on by default (T-63944, Utilities R36 MR2 Release Notes)
  • On R38, Configurator also checks read access with native Salesforce user-mode queries, which the opt-out does not switch off. See article 131455
  • Salesforce Documentation: Field-Level Security
Choose files or drag and drop files
ai_automated
Was this article helpful?
Yes
No

  1. Priyanka Bhotika

  2. Posted
  3. Updated

Comments