Skip to main content

Screen Flows and FLS: Why Field Values Silently Disappear

One of the most frustrating debugging experiences in Salesforce Flows is when a field assignment works perfectly for administrators but silently produces null values for standard users. There is no error message, no debug log warning, and no indication that anything went wrong. The record simply saves with a blank field.

The Root Cause​

Starting with API version 66.0 and later, Salesforce enforces Field-Level Security (FLS) in Flows that run in user mode. When a Flow assigns a value to a field that the running user lacks FLS read or edit access to, the platform does not throw an error. Instead, it silently strips the value. The assignment element executes successfully, but when the record is committed to the database, the restricted field is null.

This is by design. Salesforce treats FLS enforcement as a security boundary, not a validation rule. The platform assumes that if a user cannot see a field, they should not be able to write to it through automation either.

How to Diagnose the Issue​

The telltale symptoms are:

  • Admin users: The Flow works perfectly. All fields populate as expected.
  • Standard users: The Flow completes without errors, but one or more fields are blank on the saved record.
  • Debug logs: The assignment element shows the value being set, but the DML operation writes null.

To confirm FLS is the culprit, check the running user's Profile or Permission Set. Look for the specific field that is missing values and verify whether the user has Edit access to that field. If they do not, you have found your problem.

The Fix: SystemModeWithoutSharing​

The most reliable fix is to change the Flow's run mode so that it executes with full system-level field access, bypassing FLS checks. This is done by setting runInMode to SystemModeWithoutSharing in the Flow's metadata XML.

Flow Metadata XML Example​

<?xml version="1.0" encoding="UTF-8"?>
<Flow xmlns="http://soap.sforce.com/2006/04/metadata">
    <apiVersion>62.0</apiVersion>
    <runInMode>SystemModeWithoutSharing</runInMode>
    <label>Update Order Fields</label>
    <processType>Flow</processType>
    <status>Active</status>
    <!-- ... remainder of Flow definition -->
</Flow>

The <runInMode>SystemModeWithoutSharing</runInMode> element tells Salesforce to run the Flow with system-level permissions. The "without sharing" part means it also bypasses org-wide defaults and sharing rules, which is important to understand before applying it.

In Flow Builder, you can also set this through the UI: open the Flow, click the gear icon for Flow properties, and change "How to Run the Flow" to System Mode Without Sharing.

When to Bypass FLS (and When Not To)​

Use SystemModeWithoutSharing when:

  • The Flow performs backend automation that writes to fields the user should not directly edit but that the business process requires (e.g., integration status fields, internal tracking timestamps).
  • The Flow is a Record-Triggered Flow or a Screen Flow that acts as a controlled wizard where the user is not directly choosing field values.

Avoid SystemModeWithoutSharing when:

  • The Flow is a Screen Flow where the user directly inputs values into fields. In this case, FLS enforcement is appropriate because you want to respect the user's access level.
  • You are uncertain which fields the Flow touches. Running in system mode with a broad Flow can inadvertently expose or modify data the user should not access.

Key Takeaway​

If field values work for admins but silently disappear for other users in a Flow, FLS enforcement is almost certainly the cause. The fix is straightforward, but the silent failure mode makes this one of the harder issues to diagnose without prior knowledge of the behavior. Always verify FLS access for all fields a Flow modifies, or explicitly set the Flow to run in system mode when backend automation requires it.