Show or Hide a SharePoint List Form Field Based on Another Field's Value

Ask ten SharePoint admins how to hide a field until someone picks a specific option elsewhere on the form, and most will say the same thing: JSON formatting. It works. It was never built for this job, though. Column and view formatting got repurposed for forms, so you end up writing formatting schema by hand, referencing internal column names, and hoping nothing renames itself later. There's no rule library, no visual condition builder, and no warning when something breaks.

The example that comes up again and again is a request form. You've got a "Request Type" choice field with options like Equipment, Leave, and Travel, and an "Equipment Name" text field that only makes sense when someone picks Equipment. Show it always and the form looks cluttered for anyone requesting leave. Hide it with brittle JSON and you're one column rename away from a support ticket.

Hiding a field until another field matches a value

1. Find the trigger field's internal name first. In SharePoint, display names and internal names part ways the moment you use spaces or special characters. "Request Type" might become Request_x0020_Type behind the scenes. Open the list settings, click into the column, and check the URL for the real internal name before referencing it anywhere.

2. Try the native route, if only to see why people move away from it. Go to the list, open "Edit form" on the modern form, then "Configure layout," and find the JSON formatting panel for the Equipment Name field. You'd write a hidden property with an if expression comparing the Request Type value to the string "Equipment." Fine for one field, one condition. Painful once you need three fields hidden under three different conditions, each maintained as a separate block of JSON with nothing shared between them.

3. Switch to a rule instead of an expression. In Forms 365 Workspaces, open the form designer for the list and select the Equipment Name field. Rather than a formatting panel, you get a rules panel attached to the field itself. Add a rule, choose "visibleIf," and pick a field (Request Type), an operator (equals), and a value (Equipment) from dropdowns instead of typing syntax. No internal name to hunt down, because the designer already knows the field's schema.

4. Decide the default state on purpose. Should Equipment Name start hidden and appear on the condition, or start visible and hide otherwise? For a field that's genuinely optional and only relevant to one choice, hide it by default. That way new list items don't show an empty, required-looking field for choices where it doesn't apply.

5. Pair it with requiredIf when the field actually matters. A field only shown for Equipment requests should usually be required for Equipment requests too. Add a second rule, requiredIf, using the same condition. Skip this and someone can switch Request Type to Equipment, watch the field appear, and still submit the form with it blank.

6. Test every branch of the choice field, not just the one you had in mind. Pick Equipment and confirm Equipment Name shows up. Pick Leave and confirm it disappears, and that it doesn't leave behind a stale required-field error. Pick Travel too, if that's a valid option. It's easy to write a rule around two values and forget a third exists.

7. Repeat the pattern for anything more complex. Need to show a field when Request Type equals Equipment and a Cost field exceeds a threshold? Most rule-based designers let you stack conditions with AND/OR logic in the same panel. If the logic genuinely outgrows the rule builder, that's what the JavaScript API is for. Treat it as an escape hatch for logic that doesn't fit a simple condition, not the default way to hide a field.

8. Save, then check the form in an actual new-item context, not just edit mode. Conditional logic can behave differently on new items versus existing ones, especially if a field already carries a saved value from before the rule existed. Run through new, edit, and view modes before your users find the gap for you.

What can go wrong

The most common failure with native JSON is a quiet one. Someone renames a column, an internal name shifts or a lookup reference breaks, and the field stops hiding or stops showing, with nothing in the SharePoint UI explaining why. Rule-based approaches aren't immune to logic errors either. Set a requiredIf without a matching visibleIf and you can end up with a hidden field that still blocks submission because it's marked required behind the scenes. Two rules targeting the same field with conflicting conditions? Whichever one evaluates last usually wins, and that's a nasty thing to debug if you're not watching for it. Build one rule at a time, test it before adding the next, and keep the trigger field's option list stable once other rules depend on it.