System-generated queries that support enrichment related lists and direct Data Model Object (DMO) queries (e.g., in Data Explorer) depend on a specific set of fields. If these critical fields become inaccessible due to Data Governance policy configurations, SOQL queries will fail, leading to errors in various functionalities.
Incorrect FLS policy configurations can impact a wide range of functionalities. Below are specific examples of critical fields and the resulting errors you may encounter if they are blocked.
Affected Functionality: ALL SOQL queries and enrichments.
Scenario: If a user adds a field as a column in a related list and that field subsequently becomes blocked by a Data Governance policy, the related list will throw an error because the field's metadata is no longer accessible.
Example Error Message:
INVALID_FIELD: ssot__LastModifiedDate__c__f, Id, ssot__LastModifiedDate__c FROM Unified_Indv_Contact_Point_Email_dem__r \^ ERROR at Row:1:Column:94 No such column 'ssot__LastModifiedDate__c' on entity 'UnifiedssotContactPointEmailDem__dlm'. If you are attempting to use a custom field, be sure to append the '__c' after the custom field name. Please reference your WSDL or the describe call for the appropriate names.
Affected Functionality: ALL SOQL queries and enrichments.
Scenario: The Salesforce system Id field is converted to a projection against the primary key of the DMO during runtime. If this primary key is blocked, all SOQL queries against that object will fail.
Example Error Message:
Thrown: lib.gack.GackContext: shared.cdp.exceptions.CDPHandledException: INVALID_ARGUMENT: unknown column 'ssot__Id__c' [TraceId:674d01e6fa3ac4b7]
Affected Functionality: IR (Identity Resolution)-based Enrichments.
Scenario: The physical lookup on the child DMO must not be blocked. For instance, in an IR-based related list (e.g., Contact -> Contact Point Email), if the lookup field is blocked, the related list will throw an exception. For nonengagement DMOs, this lookup field is PartyId with the associated key qualifier being KQ_PartyId, and for engagement DMOs, it's IndividualId.
Affected Enrichments: IR-based, Non-IR, and DMO-DMO (Engagements Only).
Scenario: A filter is automatically applied to related lists for engagement DMOs to only show records from the last 7 days. If the date partition field used for this filter is blocked by Data Governance, the runtime query will fail.
Affected Functionality: ALL SOQL queries and enrichments that query currency fields.
Scenario: Queries involving currency fields are dependent on the exchange_rate_table DMO and the Cdp_sys_record_currency__c field. If the exchange_rate_table DMO or any of its fields are blocked, an exception will be thrown.
Affected Enrichments: DMO-DMO and Non-IR Enrichments.
Scenario: These enrichments are based on a user-defined relationship between a parent and child field. If either of these fields is blocked by Data Governance, the related list will fail.
Example Error Message:
INVALID_FIELD: No such column 'ssot__LastName__c' on entity 'ssot__Individual__dlm'. If you are attempting to use a custom field, be sure to append the '__c' after the custom field name. Please reference your WSDL or the describe call for the appropriate names.
7. Link Table Fields for Unifying Records
Affected Functionality: While not immediately breaking IR-based enrichments, these fields will cause errors if they're part of a query's projection (i.e., displayed as columns).
Scenario: Fields such as ssot__DataSourceId__c, ssot__DataSourceObjectId__c, SourceRecordId__c, KQ_SourceRecordId__c, and UnifiedRecordId__c are crucial for unifying records. If these are blocked by Data Governance policies, any query attempting to project them will fail.
To ensure system functionality, we strongly recommend that you:
Review Your DG FLS Policies: Carefully examine your Data Governance FLS policies to ensure that none of the critical fields listed above are inadvertently blocked.
Test in a Sandbox: Before deploying any new or updated FLS policies to your production environment, thoroughly test them in a sandbox to identify any potential conflicts.
Follow FLS Best Practices: When creating or modifying FLS policies, please adhere to Salesforce's recommended best practices for field-level security.
To ensure system functionality, we strongly recommend that you:
Review Your DG FLS Policies: Carefully examine your Data Governance FLS policies to ensure that none of the critical fields listed above are inadvertently blocked.
Test in a Sandbox: Before deploying any new or updated FLS policies to your production environment, thoroughly test them in a sandbox to identify any potential conflicts.
Follow FLS Best Practices: When creating or modifying FLS policies, please adhere to Salesforce's recommended best practices for field-level security.
If you encounter any of the issues or error messages described in this document, or if you require assistance diagnosing your Data Governance FLS policy configurations, please contact our support team.
See Help Content for Data Governance:
005132306

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings.
Privacy Statement
Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.
Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.
Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.