We deployed our custom account sync integration to production using Summer '23 release and Salesforce CLI. The deployment succeeded without errors, but now our nightly account synchronization jobs are failing with “REQUIRED_FIELD_MISSING” errors.
The error occurs specifically when trying to update Account records from our external ERP system. I’ve checked the Metadata API deployment logs and everything shows as successful. However, custom fields that were working fine in our sandbox are now blocking the sync.
ERROR: REQUIRED_FIELD_MISSING
Field: Account.External_ERP_ID__c
Required fields missing: [External_ERP_ID__c]
Field-level security settings appear correct in the UI, and the integration user has full permissions. The Change Set included all custom fields and the integration user profile. Has anyone encountered field visibility issues after Summer '23 cloud deployments? This is blocking our critical account data flow.
Check your field-level security settings in the deployed profile. Summer '23 introduced stricter validation for FLS during Metadata API deployments. Even if the field exists, the integration user profile might not have explicit read/write access after deployment.
Quick workaround while you fix the deployment: Navigate to Setup → Profiles → Integration User Profile → Object Settings → Accounts → Edit, then enable field-level security for External_ERP_ID__c. This will immediately unblock your sync jobs.
Here’s the comprehensive solution addressing all three focus areas:
Metadata API Deployment Fix:
The core issue is incomplete field permission deployment. Create a proper deployment package using Salesforce CLI with explicit field permissions:
sf project retrieve start -m "CustomField:Account.External_ERP_ID__c,Profile:Integration_User"
Verify the retrieved Profile XML includes field permissions:
<fieldPermissions>
<field>Account.External_ERP_ID__c</field>
<readable>true</readable>
<editable>true</editable>
</fieldPermissions>
Deploy using: `sf project deploy start -d force-app
Field-Level Security Resolution:
Summer '23 enforces FLS validation at API level even when UI shows access. After deployment, verify permissions using Workbench or execute this in Anonymous Apex:
Schema.DescribeFieldResult fieldDescribe = Account.External_ERP_ID__c.getDescribe();
System.debug('Updateable: ' + fieldDescribe.isUpdateable());
Change Set Troubleshooting Best Practices:
- Always include both CustomField AND Profile components in Change Sets
- After adding profiles, click “View/Add Profile Settings” and explicitly select field permissions
- Use “Validate Deployment” before deploying to catch FLS issues
- For complex deployments, switch to Salesforce CLI with source-driven development
- Document which metadata types require explicit permission components
Immediate Fix: Manually grant field access as suggested earlier, then properly redeploy with correct metadata package.
Prevention: Implement a deployment checklist that validates field permissions are included in package.xml for all custom fields. Use permission sets instead of profile modifications where possible, as they deploy more reliably. Consider using SFDX project structure which handles these dependencies automatically.
This approach ensures your Metadata API deployments include all necessary field-level security settings and prevents similar issues in future Change Set deployments.
This is a common Change Set troubleshooting scenario. When you deployed via CLI, did you use a package.xml that explicitly included the field permissions? Summer '23 changed how field permissions are validated during deployment. Try this query to verify current permissions:
SELECT Field, PermissionsEdit, PermissionsRead FROM FieldPermissions WHERE SobjectType = ‘Account’ AND ParentId IN (SELECT Id FROM PermissionSet WHERE Profile.Name = ‘Integration User’)
If the field permissions are missing, you’ll need to redeploy with corrected metadata.
I’ve seen this exact issue. The problem is that Change Sets don’t always properly deploy field-level security for custom fields, especially when profiles are modified separately. You need to verify that your deployment package included both the custom field definitions AND the field permissions in the profile metadata. Run a retrieval using Salesforce CLI to compare what’s actually deployed versus what you intended. Look specifically at the profile XML to confirm External_ERP_ID__c has read and edit permissions set to true.
Thanks for the suggestions. I ran the query and confirmed the field permissions are indeed missing from the integration user profile in production. The sandbox shows them correctly, but they didn’t transfer with the Change Set. This explains why the UI shows access but the API calls fail.