Cascading dropdown in a SharePoint list form

Short answer: a SharePoint list has no built-in cascading dropdown, because Microsoft's pages on the list form do not describe one. For filtered options, use a Power Apps custom form with a Filter formula on the child dropdown, which Microsoft documents as a dependent drop-down list. Without Power Apps, the closest option is show-if rules on separate Choice columns, which is not a true cascade.

What "cascading" means

A cascading dropdown (Microsoft also says dependent drop-down) works in two steps. A person picks a value in the first list. The second list then shows only the options that belong to that first value.

Examples:

Request type, then Detail. "IT" shows Laptop, Password, Software. "Facilities" shows Desk, Parking, Repair.
Region, then Office.
Category, then Subcategory.

The point is to stop wrong pairs, like a Detail of "Parking" on an "IT" request.

The two formulas, from Microsoft's example

Microsoft's Power Apps example stores parent and child values in a separate list called Locations, with a Location column and a Department column. Two formulas do the work.

Parent dropdown, Items property: Distinct(Locations, Location)
Child dropdown, Items property: Filter(Locations, Location = ddLocation.Selected.Result)

In the example, ddLocation is the parent dropdown. Power Apps writes the second formula for you when you select the child dropdown and choose Depends on.

If the child dropdown shows duplicates, Microsoft says "To remove the duplication, wrap a Distinct function around the properly returning data."

To check the child dropdown, select it and read the Items property in the formula bar. It should show the Filter formula above, with your own list and column names.

Without Power Apps

Microsoft's pages do not show a way to filter the options of a Choice or lookup column by the value of another column in the built-in list form. The built-in form can show or hide a whole column based on another column's value. That is the closest option, and it is not a true cascade, because the person sees separate columns instead of one list that changes. Option 1 below explains the setup.

What Microsoft documents

Microsoft's page for the built-in form tools, "Show or hide columns in a list form", describes a conditional formula that shows or hides a column based on another column's value. That page does not describe filtering the options inside a dropdown.

Microsoft's page "Create list relationships by using lookup columns" describes how a lookup column pulls a value from a column in another list. It does not describe filtering the lookup by another column.

Microsoft's Power Apps page "Create a dependent drop-down list in a canvas app" does describe it. Users select an option in one list to filter the options in another list. The page uses a SharePoint list as the data source and a custom form, opened from the list with Integrate, then Power Apps, then Customize forms. Exact names may differ.

So the plain reading is this. In the built-in form, you get show-if rules and lookups. For true filtered options, Microsoft documents the Power Apps form.

Three ways to get close

Here is each option, with what it does and what it costs you.

Option 1. Show-if rules in the built-in form.

Make one Choice column per group of details. For example, "Detail (IT)" and "Detail (Facilities)".
Add a conditional formula to each, so it shows only when Request type has the matching value.
This is not a true cascade. The person sees one Detail column at a time, and each has its own list of choices.
It needs no Power Apps and no second list.
Unsupported column types matter. Microsoft lists these as not supported: Person or Group with multiple selections, Choice with multiple selections, Lookup with multiple selections, time calculations in Date and Time, Currency, Location, Calculated and Managed Metadata. Use a single-select Choice as the trigger.

Option 2. A lookup column to a second list.

Keep the details in a second list. The first list picks from it with a lookup column.
A lookup column shows values from the source list. Microsoft's page does not describe filtering that drop-down by another column. So the person sees every detail, not only the ones for the chosen type.
Use it when you want one place to edit the list of details and do not need the filtering.
Microsoft lists the source column types a lookup can use: Single line of text, Number, Date and Time, and Lookup (single value). A Choice column is not on that list.

Option 3. A Power Apps form with a filtered dropdown.

Keep the parent and child values in their own list. Microsoft calls this a best practice.
Replace the form with a custom form. The child dropdown shows only the rows that match the parent.
This is the only option of the three that Microsoft describes as a dependent drop-down.
Someone must maintain the form. It is also a different kind of thing to keep up than the built-in form. See "Power Apps or a SharePoint list form: which one do you need?".

Decision list

Use this order. Stop at the first line that fits.

Do you have two or three first-level values with a few details each? Try Option 1, show-if rules. It needs no extra list. Our advice, not a Microsoft rule: this fits a short list of first-level values.
Do you only need one list of details to pick from, and wrong pairs are not a problem? Use Option 2, a lookup column. See "SharePoint lookup column shows blank or too few fields".
Do you need the second list to show only matching rows? Use Option 3, a Power Apps form.
Is the second choice just a note nobody reports on? Keep it simple. Use one Choice column.

For a quick read on when a custom form is worth it, see "Power Apps or a SharePoint list form: which one do you need?".

Worked example: Request type, then Detail

The team runs an internal request list. Each request has a Request type and a Detail. The goal is that Detail shows only the details for the chosen type. This uses Option 3, because it is the one Microsoft documents for filtering.

The lists:

Requests: the list people fill in. Columns are Title (holds the request summary), Request type (Single line of text), Detail (Single line of text) and Needed by (Date).
Request details: the source list of allowed pairs. Columns are Title (the detail name) and Request type (Single line of text).

Microsoft's page creates the columns the form fills in as Single line of text. It says this simplifies configuration and avoids delegation warnings in Power Apps.

Rows in Request details:

Laptop, 1 IT
Password, 1 IT
Software, 1 IT
Desk, 2 Facilities
Parking, 2 Facilities
Repair, 2 Facilities

Steps. Exact names may differ.

Create the Request details list and add the six rows above.
Open the Requests list. Choose Integrate, then Power Apps, then Customize forms.
In the Fields pane, open the Request type field and change the Control type to Allowed Values. It becomes a Drop down control. Do the same for the Detail field.
Add the Request details list as a data source in Power Apps.
Select the Request type card. On the Advanced tab, choose Unlock to change properties. Do the same for the Detail card.
Rename the two Drop down controls ddType and ddDetail so the formulas are easy to read.
Set the Items property of ddType to Distinct('Request details', 'Request type'). Use your own list and column names, in single quotes if they have spaces.
Select ddDetail. On the Properties tab, choose Depends on. Set the parent control to ddType with Result. Set the matching field to the Request type column of the Request details list. Select Apply.
Power Apps sets the Items property of ddDetail to a Filter formula of this shape: Filter('Request details', 'Request type' = ddType.Selected.Result).
On the Properties tab, set the Value of ddDetail to the detail name column.
Test it. In Power Apps Studio, hold Alt, open the Request type list and pick a type, then open the Detail list. It should show only that type's details.
Choose File, then Save, then Publish to SharePoint. Open the Requests list, choose New and check the form.

Two things from the same Microsoft page. If the child list shows duplicates, Microsoft says to wrap the returned data in a Distinct function. The Depends on setting does not work on controls that allow multiple selections, and it does not support static data or collections.

The simpler version of the same example

If the example has only two or three types, try Option 1 first.

In the Requests list, make a Choice column named RequestType, with no space, and the values 1 IT, 2 Facilities and 3 HR. Then rename it to "Request type". The internal name stays RequestType.
Make three Choice columns: "Detail (IT)", "Detail (Facilities)" and "Detail (HR)".
Open any item, choose Edit form, then Edit columns. Exact names may differ.
For "Detail (IT)", open the options menu (...) and choose Edit conditional formula.
Enter: =if([$RequestType] == '1 IT', 'true', 'false')
Repeat for the other two, using '2 Facilities' and '3 HR'.
Save and test with a new item.

The text in quotes must match the choice exactly, including the number. The name in square brackets is the internal name of the column, which can differ from the name on screen.

The cost: you have three Detail columns in the list. Reports and views have to read all three.

What to avoid

Do not build a second list of details if you have five details in total. A Choice column does the job.
Do not expect a lookup column to filter itself. Microsoft's lookup page does not describe that.
Do not use a multi-select Choice as the trigger for a show-if rule. Microsoft says it is not supported.
Do not type the choice text from memory in a formula. Copy it, including the number.
Do not put the parent and child values only inside the form. Microsoft recommends a data source for them that is separate from the list users fill in. Then you can change values without republishing the app.
Do not try to link two Choice columns in Power Apps with no source list behind them. Microsoft says Power Apps does not support two choice fields in SharePoint without a matching table of data.
Do not treat hiding a column as security. Anyone with access to the list can still reach the data.

When to keep it simple

Skip all of this and use one Choice column when:

The second choice has a short list of values that do not change with the first.
Nobody reports on the second choice.
The wrong pair is caught by a person anyway.
The team does not want a custom form to keep up.

A single Choice column with a clear name is easier to explain, easier to hand over and easier to fix.

If the real problem is that the form is long, see "Make the new-item form shorter: sections and show-if rules".

Test before you tell the team

Make a test item for each first-level value.
Check that the second choice shows only the matching options.
Change the first value on an existing item. Check what happens to the second value. A value saved earlier may no longer match.
Open the form as a person with limited access. Microsoft says people with only item-level permissions do not get a Power Apps customized form.
Save, then open the item again to confirm both values were kept.

When to get help

You can build all of this yourself in Microsoft 365. If you would rather have it built and tested for your team, I do that. A tracker like this is a fixed price: $5,000 for one, built in 2 weeks. See "What a SharePoint tracker costs to build". Bring one example of the problem to a free call.

Tell me what's still manual

I am Al Davies. I run 250 High Street LLC and build SharePoint trackers and Power Automate flows for operations teams. I work remotely. The first call is free, and I will not try to sell you anything.

See trackers I built: Tools I built

FAQ

Can I make a cascading dropdown in a SharePoint list without Power Apps?

Microsoft's pages do not show a way to filter one column's options by another in the built-in form. The closest option is a conditional formula that shows or hides separate Choice columns.

Is a dependent dropdown the same as a cascading dropdown?

Yes. Both mean one list filters another. Microsoft documents it for Power Apps custom forms, using a Filter formula on the child dropdown.

Can JSON formatting make a cascading dropdown in a list form?

Microsoft's page for the built-in form describes conditional formulas that show or hide a whole column. It does not describe filtering the options inside a dropdown.

What are the Power Apps formulas for a cascading dropdown?

Parent Items: Distinct(Locations, Location). Child Items: Filter(Locations, Location = ddLocation.Selected.Result). These come from Microsoft's example, so swap in your own names.

Can I filter a lookup column by another column?

Microsoft's lookup column page does not describe filtering. The lookup shows values from the source list. For a filtered second list, Microsoft documents the Power Apps form.

Can I use a Choice column as the source of a lookup?

Not per Microsoft's list of supported source types: Single line of text, Number, Date and Time, and Lookup (single value). Use a Single line of text column in the source list.