Conditional Required Fields in SharePoint: Make One Field Depend on Another

The problem: a reason field that should sometimes be mandatory

Picture a Requests list with a Status column (New, Approved, Rejected, On Hold) and a Reason for Rejection column. Nobody filling in Approved should be forced to type a reason. But the moment Status flips to Rejected, that reason field has to be filled in. Every time. No exceptions. Skip the enforcement and someone will forget, and three months later a manager is asking why forty rejected requests have no explanation attached.

That's a conditional required field. It sounds like a small ask. Native SharePoint doesn't make it easy.

How teams patch this together today

The Required setting on a SharePoint column is a single switch: on or off. Column settings have no option for "required, but only when Status equals Rejected." So teams reach for workarounds, and each one costs something.

The most common fix is a column validation formula, something like =IF(Status="Rejected", NOT(ISBLANK(Reason)), TRUE). As a save-time check, it works: SharePoint blocks the item from saving if the condition fails. But two problems show up fast in practice. The error only appears when the user hits Save, not while they're filling out the form, so someone can set Status to Rejected, skip the reason, submit, and get bounced back with a message that doesn't point clearly at what needs fixing. Worse, the Reason field never actually looks required. No red asterisk, no visual cue, just a rejection at the end. Users find that confusing, and support tickets follow.

Some teams try to close the visual gap with column formatting JSON on the form, adding an asterisk or changing the field's colour when Status equals Rejected. That helps with appearance, nothing more. JSON formatting doesn't stop a blank submission by itself. Unless it's paired with a validation formula or a Power Automate flow checking the same condition afterwards, the field only looks required. It isn't enforced.

The other route is customising the list form in Power Apps. Once you're in Power Apps, this problem already has an answer: select the Reason data card, set its Required property to a formula such as If(Status.Selected.Value = "Rejected", true, false). That's a proper conditional rule, and it marks the field visually and blocks submission. What it costs is everything that comes with it. You're no longer editing the default SharePoint list form, you're maintaining a full custom Power Apps form, with its own screens, its own version of every other field, and its own quirks whenever the list schema changes. For one conditional field, that's a lot of infrastructure to take on.

Anyone who used InfoPath years ago remembers this being easier. InfoPath had rule-based required fields built in. Losing that when list forms took over left a real gap for a lot of organisations, and it wasn't just nostalgia talking.

Setting it up with a requiredIf rule instead

This is exactly the case a requiredIf rule is built for. In Forms 365 Workspaces, open the form designer for the Requests list, select the Reason for Rejection field, and add a rule: require this field when Status equals Rejected. The rule points at the Status column and the value Rejected directly. No formula syntax to get right, no separate JSON for the visual side.

The difference from a validation formula is that enforcement and visibility live in the same place. When the condition is true, the field shows as required, the marker appears, and the form won't submit until it's filled in. When the condition is false, the field isn't required at all. Depending on how the form is set up, it's often worth hiding it too with a paired visibleIf rule. There's rarely a good reason to show a rejection reason box to someone approving a request.

More than one status can trigger the rule if the business logic calls for it. If Reason should also be required for On Hold, the condition just needs to check for either value instead of a single exact match. The designer's placeholder and expression syntax handles referencing other fields on the form, so the rule can compare against Status, or against a calculated value elsewhere on the form, without a flow or a background script doing the work.

It's the same problem Power Apps solves with its Required formula on a data card. What changes is where that logic sits. Instead of rebuilding the form in a different tool for one conditional field, the rule lives directly on the SharePoint list form, alongside the other rules for that form, visible to whoever edits it next. Whether it's one conditional required field or a dozen spread across different columns, that's a lot less to maintain than a parallel Power Apps form.