Data transform without field-level security
Why is this an issue?
Field-level security (FLS) controls which fields a user is allowed to read and edit. OmniStudio Data Mappers run server-side and can access any field referenced in their mappings. When FLS enforcement is turned off, the Data Mapper reads and writes fields regardless of the running user's permissions.
This bypasses the org's FLS configuration: a user who should not see a field (for example, a salary or a national identifier) can receive its value through the transform, and a user who should not edit a field can have it written on their behalf. This is a common source of data-exposure and integrity issues in OmniStudio implementations.
This rule applies only to Data Mappers (metadata type OmniDataTransform, formerly DataRaptor). OmniScripts, Integration Procedures, and FlexCards / Vlocity Cards are out of scope. Note that the two variants differ in how they treat a missing flag: the OmniStudio rule reports only an explicit fieldLevelSecurityEnabled = false, whereas the Vlocity rule reports a DataRaptor whenever field-level security is not explicitly enabled — including when the flag is absent.
Examples
Example of incorrect code:
<OmniDataTransform>
<fieldLevelSecurityEnabled>false</fieldLevelSecurityEnabled>
</OmniDataTransform>
Example of correct code:
<OmniDataTransform>
<fieldLevelSecurityEnabled>true</fieldLevelSecurityEnabled>
</OmniDataTransform>
For Vlocity DataPacks the same setting is expressed in JSON. Incorrect:
{ "IsFieldLevelSecurityEnabled": false }
Correct:
{ "IsFieldLevelSecurityEnabled": true }
How can I fix violations?
Enable field-level security on the data transform so that reads and writes respect the running user's field permissions:
In the OmniStudio designer, open the Data Mapper's Options tab and turn on Check Field Level Security.
In the underlying metadata, set the field-level-security flag to
true:OmniStudio XML: the
fieldLevelSecurityEnabledelement.Vlocity DataPack JSON: the
IsFieldLevelSecurityEnabledfield, or the namespaced%vlocity_namespace%__CheckFieldLevelSecurity__cfield in older DataPacks.
This rule covers field-level security only. Data encryption is a separate concern, even though Salesforce governs both through the same org-wide EnforceDMFLSAndDataEncryption setting.
When should I disable this rule?
If your org enforces field-level security for every Data Mapper through the org-wide EnforceDMFLSAndDataEncryption setting, this rule's findings are redundant and you may disable it. That setting is created as an Omni Interaction Configuration record (Name and Label EnforceDMFLSAndDataEncryption, Value true) and applies FLS to all Data Mappers regardless of each transform's own Check Field Level Security flag, so a Data Mapper reported here is still protected at run time.
Some system-level integrations intentionally run without FLS — for example, a transform executed only by an automated, fully privileged integration user where enforcing FLS would break the integration. In those narrowly scoped cases you may dismiss the specific instance, provided the transform is never reachable by end users.
Resources