Integration with external system fails due to data classification security restrictions

CRM Salesforce
, , , , , , , ,
1

Our integration with an external analytics system is failing due to data classification security restrictions in Winter '25. The integration worked fine until we implemented Salesforce’s data classification features, and now sync operations are being blocked.

The external system pulls contact and account data for analytics and reporting. We use a dedicated integration user account with an Integration profile. After enabling data classification and marking certain fields as ‘Confidential’ and ‘Restricted’, the integration started failing with access denied errors.

The integration user has ‘View All Data’ and ‘Modify All Data’ permissions, which should grant access to all records. However, the API calls return errors indicating insufficient field-level security for classified fields. We’ve classified fields like SSN, Credit_Score__c, and Internal_Notes__c as Restricted, and fields like Annual_Revenue__c and Employee_Count__c as Confidential.

We need these data classification labels for compliance purposes, but the integration requires access to some of these fields for legitimate business analytics. How do we grant the integration user access to classified fields without compromising our data governance model? Is there a way to selectively allow integration users to access classified data while maintaining restrictions for regular users?

2

Create a permission set specifically for integration users that grants field-level read access to the classified fields they legitimately need. Don’t grant access to truly sensitive fields like SSN unless absolutely required. For fields like Annual_Revenue and Employee_Count marked as Confidential, the integration probably does need access for analytics, so include those in the permission set.

Also review your data classification policy. Not every field needs a classification label. Reserve Restricted classification for truly sensitive PII, and use Confidential for business-sensitive data that still has legitimate use cases in integrations.

3

Correct. Data classification labels in Salesforce are metadata tags that identify sensitive data for compliance reporting, data privacy assessments, and governance dashboards. They don’t enforce access restrictions directly. Field-level security and object permissions control who can actually read or edit fields. You need both: classification labels for visibility into what data you have and where it lives, and FLS to enforce who can access it. For your integration, grant FLS access to the fields needed while maintaining the classification labels for compliance documentation.

4

Your integration failure results from a misunderstanding of how Salesforce data classification interacts with field-level security and user permissions. Resolving this requires a comprehensive review of your security model across three distinct layers: data classification labels, field-level security configuration, and integration user permissions.

First, conduct a field-level security review specifically for your integration user profile. Data classification labels in Salesforce are descriptive metadata tags that identify the sensitivity level of data for compliance and governance purposes. They do not automatically enforce access restrictions. Field-level security (FLS) is the mechanism that controls whether a user or profile can view or edit specific fields. When you applied classification labels to fields like SSN, Credit_Score__c, and Annual_Revenue__c, you correctly identified them as sensitive for governance purposes, but this action alone doesn’t change who can access them. Your integration user’s ‘View All Data’ and ‘Modify All Data’ permissions grant access to all records at the object level, but field-level security operates independently. Navigate to Setup > Profiles > Integration Profile > Field-Level Security. For each classified field your integration requires, verify that read access is explicitly granted. If you see ‘No Access’ for fields like Annual_Revenue__c or Employee_Count__c, your API calls will fail with field permission errors regardless of object-level permissions. Enable field-level read access for business-necessary classified fields while keeping truly sensitive fields like SSN restricted unless absolutely required for the integration’s business purpose.

Second, implement data classification labels as part of your governance framework without conflating them with access control. Classification labels serve three primary purposes: Compliance documentation - they help you demonstrate to auditors that you’ve identified and tagged sensitive data according to regulations like GDPR, CCPA, or HIPAA. Data discovery - they enable you to quickly locate all fields containing specific types of sensitive information across your org using the Data Classification dashboard. Privacy impact assessments - they facilitate analysis of what sensitive data exists in which objects and how it flows through your systems. Your current classification scheme - Restricted for SSN/Credit_Score, Confidential for Annual_Revenue/Employee_Count - is appropriate for compliance visibility. Maintain these labels even as you adjust field-level security for integration access. The labels document the sensitivity level, while FLS enforces who can access the data. These are complementary controls, not redundant ones.

Third, review and refine integration user permissions through a dedicated permission set that balances security with operational requirements. Rather than modifying the Integration profile directly (which might affect multiple integration users), create a permission set named ‘External Analytics Integration Access’ that grants field-level read access to specific classified fields your analytics integration legitimately requires. Include these fields: Annual_Revenue__c (Confidential) - needed for revenue analytics, Employee_Count__c (Confidential) - needed for customer segmentation, and Internal_Notes__c (Restricted) - evaluate whether analytics truly needs this field; if not, exclude it. Explicitly exclude SSN and Credit_Score__c unless your analytics platform has documented business requirements and appropriate security controls for this data. Assign this permission set only to the dedicated integration user account, not to general user profiles. This approach provides granular control and clear audit trails showing exactly which integration accounts have access to classified data and why.

Implement a three-tier field access strategy for your integration: Tier 1 (Open Access) - non-classified fields and fields classified as Public - grant full read access, Tier 2 (Conditional Access) - fields classified as Confidential that have legitimate business use in analytics - grant read access via permission set with documented business justification, Tier 3 (Restricted Access) - fields classified as Restricted containing PII or highly sensitive data - deny access unless absolutely required and approved by security team. For your current integration, Annual_Revenue and Employee_Count fall into Tier 2 (grant access), while SSN and Credit_Score fall into Tier 3 (maintain restrictions unless analytics platform has specific compliance requirements).

Document your field access decisions in a data access matrix that maps: Field name, Classification label, Integration access granted (Yes/No), Business justification, Compliance considerations. This documentation demonstrates to auditors that access decisions are deliberate and risk-based rather than arbitrary. For example: ‘Annual_Revenue__c - Confidential - Access Granted - Required for revenue trend analysis and customer segmentation in analytics platform - No PII, business confidential only, analytics platform has appropriate access controls’.

For your immediate resolution, execute this sequence: First, navigate to Setup > Profiles > Integration Profile > Object Settings > Account and Contact. Second, for each classified field your integration needs (Annual_Revenue__c, Employee_Count__c, Internal_Notes__c if required), set field-level security to ‘Read’ access. Third, test your integration API calls to verify they now successfully retrieve classified fields. Fourth, for fields that should remain restricted (SSN, Credit_Score__c), confirm field-level security remains ‘No Access’ and modify your integration queries to exclude these fields. Fifth, update your integration error handling to gracefully manage field permission errors rather than failing entirely when encountering restricted fields.

One important consideration: if your organization implements Salesforce Shield Platform Encryption in the future for additional protection of classified fields, integration users will need the ‘View Encrypted Data’ permission to access encrypted fields. Plan for this in your permission set design now to avoid future integration failures when encryption is deployed.

This layered approach - maintaining data classification labels for governance visibility while carefully managing field-level security for operational access - enables you to meet compliance requirements without blocking legitimate business integrations.