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]

Or:

Field Level Security error: User does not have edit access to field [Field_Name] on object [Object_Name]

These errors prevent users from completing their work and may block critical business processes.

Root Cause

CloudSense Release 37 introduced new fields or modified existing field usage patterns across various CloudSense managed packages. If your org's Field Level Security (FLS) settings were not updated to grant the necessary permissions to user profiles or permission sets, CloudSense processes will fail when attempting to read or write to these fields.

Common scenarios include:
- New fields added in R37 that require read/write access
- Existing fields that now require different permission levels
- Profile or permission set configurations that were not refreshed after the upgrade
- Custom profiles that do not inherit FLS settings from CloudSense permission sets

Resolution

Step 1: Identify the Affected Field and Object

1. Review the full error message to identify:
2. The object name (e.g., cscfga__Product_Configuration__c)
3. The field name (e.g., cscfga__product_discount__c)

4. The operation that failed (read, create, update)

5. Note the user profile or permission set 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. Scroll down to Field-Level Security
7. Review which profiles and permission sets have Visible and Read-Only access

Step 3: Grant Appropriate Field Access

1. In the Field-Level Security section, click Set Field-Level Security
2. Locate the profiles or permission sets used by the affected users
3. For each profile/permission set:
4. Check Visible
5. Check Read-Only (if the field should be editable, leave this unchecked)

6. If the field needs to be editable, ensure Read-Only is unchecked

7. Click Save

Alternative Method (Profile-Based):
1. Navigate to Setup > Users > Profiles
2. Select the profile 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. Check Read Access and Edit Access as appropriate
8. Click Save

Step 4: Assign CloudSense Permission Sets (Recommended)

CloudSense provides managed permission sets that include all necessary FLS settings for R37. Assigning these permission sets is the most reliable way to ensure proper field access:

1. Navigate to Setup > Users > Permission Sets
2. Locate CloudSense-provided permission sets for the relevant package:
3. cscfga_Admin (Configurator)
4. cssmgnt_Admin (Solution Management)
5. csord_Admin (Orders & Subscriptions)
6. cspofa_Admin (Orchestrator)
7. cspmb_Admin (Pricing)

8. csdf_Admin (Digital Fulfilment)

9. Open the appropriate permission set

10. Click Manage Assignments
11. Click Add Assignments
12. Select the affected users
13. Click Assign

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
2. Repeat Steps 3-4 for each profile or permission set
3. Notify users that the issue has been resolved

Prevention

For Salesforce Administrators

• Post-Upgrade FLS Review: After every CloudSense package upgrade, review release notes for new fields and update FLS settings accordingly
• Permission Set Strategy: Use CloudSense-provided permission sets rather than manually configuring FLS on custom profiles
• Testing: Test all critical CloudSense operations 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, review the release notes for new fields and plan FLS updates
• 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

Related Information

• Affected Release: CloudSense R37 and later
• Affected Objects: All CloudSense managed objects (varies by package)
• Common Fields: New fields introduced in R37 (varies by package)
• Related Permissions: CloudSense Admin permission sets
• Salesforce Documentation: Field-Level Security