The Small Salesforce Flow Setting That Changes User Behavior

By Neil Foglio | August 6, 2026

As Salesforce Admins, we often build Screen Flows to capture answers. But some workflows need to capture something more nuanced: user intent. In these cases, we need to know not only what a user entered, but also whether they reviewed existing information, confirmed it was still accurate, or actively changed it. A standard editable field can’t tell you the difference.

That is where the usability of a Screen Flow becomes just as important as the automation behind it. A well-designed Flow does more than reduce clicks. It helps users understand what they are being asked to do, gives them confidence as they move through a process, improves the quality of data in Salesforce, and gives admins better insight into real user behavior.

In this post, you’ll see how pairing a simple boolean toggle with the Read Only and Disabled component settings of an input field can give users a clear, guided experience, while also giving downstream automation the behavioral signals it needs to respond to what happened on the screen.

Admins are accidental usability designers, too

Usability is the technical term for how well a system supports the people using it, including whether they can understand what to do, complete the task efficiently, avoid mistakes, feel confident along the way, and willingly come back to use it again.

Some organizations devote entire teams to this. Before launching a high-volume application, they might run formal usability studies to observe how people move through a screen: where their eyes go first, how far their mouse travels, how long they pause before taking action, whether they backtrack, and where they show signs of frustration or praise. In my experience, these studies can surface problems beyond the requirements on the page by revealing a field everyone skips over, a button people hunt for, or a step where users consistently hesitate. The payoff of keeping usability top of mind, whether through feedback or intentional design, is a system shaped around real behavior with friction designed out before a broader launch.

As a Salesforce Admin, you’re a usability designer too. You may not run a scientific study on every Screen Flow, but you can apply the same core principles every day: reducing unnecessary clicks, writing clear field labels, grouping related information, removing clutter, preventing avoidable errors, and making the next step obvious. These choices seem small, but they decide whether Salesforce feels like a trusted system of work or just another place users are forced to enter data.

When editable fields weren’t enough: a real intake form and its sneaky design problem

This is where a small flow setting can have a much larger impact than you might think. The Disabled and Read-Only properties on a screen component sound fixed, but they can become dynamic behavioral cues when paired with formulas and screen logic. With these settings, you can control whether or not users can navigate, modify, or copy from a field. They can help separate viewing from editing, prevent accidental changes, and create a clearer moment when the user intentionally takes action to enter a different part of the process.

These were so critical in crafting an intake flow for ICAN California Abilities Network, a nonprofit that provides life skills training, supported employment, and social programming to empower people with disabilities to discover and achieve their goals. Here were their requirements:

The annual intake form asks about 50 questions, ranging from demographics, emergency contact details, personal likes and dislikes, care providers, and health conditions
If the client filled out the form previously, last year’s response would pre-populate
The client can make edits to pre-populated fields
The case manager reviewing the form needs to know which sections were updated
The intake form will be on an Experience Cloud site

At first glance, this seems like a standard flow. It’s a lot of fields, sure, and that might mean repetitive flow work. And when the form is pre-populated, we’ll just let the client edit the values, right?

The issue is that an editable field only tells us the current answer. It does not tell us whether the pre-populated field was actively reviewed, whether it was changed, or whether the case manager should pay closer attention to that section. For an intake form with dozens of questions, that distinction matters. A client may confirm that last year’s emergency contact is still correct, but update their care provider. They may leave most demographic information unchanged, but revise a health condition. From the case manager’s perspective, those updates are signals that something may require review.

So the design question is… how do you let the client update information when needed, while also preserving a clear signal that a section changed?

The Read Only and Disabled component settings have entered the chat

The Read Only and Disabled component settings optionally accept a boolean value to make the field uneditable. When set to True, Read Only fields can’t be edited, but users can still highlight or copy text, or scroll through it. Text in Disabled fields is grayed out and prevents copy-pasting. In addition to accepting a boolean value, these settings also accept a boolean formula resource, and this is where the magic happens.

By tying the field state to a toggle, we give users an interactive button to indicate they want to make a change. Follow along with me, and I’ll show you how.

1. First, create some form fields, then create a toggle on the same screen. I like to start toggle API names with “tgl” so I can find them easier in flows. In this example, the API name is tgl_update_client, and the label is “I need to add or update applicant information.” 2. Now, create a new boolean formula resource. We want the boolean result to be the inverse of the toggle state – that is, if the toggle is off, we want the boolean to return True so all the fields are locked. If the toggle is on, we want the boolean to return False to unlock the fields. As a best practice, I start my formula resources with “for” and add a capital letter for the return type. Don’t forget to leave a description for other admins!

3. Back on the Screen element, add your new formula resource to either the Read Only or Disabled setting on all your fields. Because the form respondents will already exist in Salesforce, we won’t let them edit their name or date of birth, so these fields will be permanently disabled with a static boolean. Great! Now our field editability is directly linked to the toggle state.

Let’s pause for a minute and think about the user behavior. When an applicant is filling out the form and they need to make an update, they’ll use the toggle to unlock the fields. They’ll make their update, and then click Next.

Or will they?

What if they think they need to uncheck the toggle to “lock in” their response? That’s a valid pathway, because their edits will appear set in stone and grayed out, but that wouldn’t be ideal for our workflow because then we’d lose the intentional data point of the toggle state that they made a change.

To solve for this, let’s also disable the toggle when the toggle’s value is set to True. Doing so locks the toggle state to True when the button is clicked, preventing confusion as to whether the applicant needs to lock in their edits.

4. On our screen element, select the toggle. Set the disabled value to the value of the toggle itself (tgl_update_client.value). Now, when the toggle is set to True, Disabled is also set to True – so when the toggle is set, it cannot be unset because the toggle is now disabled.

Testing the behavior, not just the build

When the screen loads, all fields except the toggle are disabled – test passed. Where we have information in our Salesforce database, fields are pre-populated.

Now you have a responsive form that makes it very clear to the user what will happen. There is just one step left – let’s capture this behavioral data and write it to a record for our case managers. To do this, we simply need to write the toggle value to a checkbox field at the end of our flow.

One important caveat to watch out for here: toggles behave similar to checkboxes, and are not always initialized to a default value of False. If the screen the toggle is on is skipped, or the toggle is hidden by conditional visibility, its value may remain null. Flows will error if you try to write null values to boolean fields. If your Flow branches or skips screens and you need to capture the toggle state as False, set it statically in an Assignment element before the record update.

Now that you have each toggle written to the record, you can create a section of the page layout that tells the case manager which portions of the form were changed.

A setup for success: from captured intent to an efficient review workflow

And now you’ve set us up neatly for a second phase enhancement: in the next iteration of this workflow, we can use these indicators in an internal screen flow that displays the updated information to the case manager and updates related records automatically.

Although this particular example comes from a nonprofit intake process, the underlying pattern is broadly reusable. Any time you want to separate viewing from editing, or capture the moment a user deliberately takes action, these same Read Only and Disabled techniques apply, and they aren’t limited to forms. You might use them when a customer updates their contact details, a rep verifies account information before a call, or a patient confirms their medications.

Next time you’re designing a screen flow, start with this question: what do your downstream stakeholders need to know about how someone interacted with the screen, beyond what they entered? If the answer is anything more than “their final answers,” Read Only and Disabled settings paired with a boolean toggle are worth reaching for. They can invite users into the process you are designing for them, reduce the chance of avoidable mistakes, and preserve the signals your internal teams need after the screen is submitted. Turning automation, data, and user behavior into a usable system that makes sense? Now that’s Salesforce Admin work.