3 alternatives to building cascading drop-downs in SharePoint
Ever since we got metadata in SharePoint, we had requirements for cascading drop-downs in SharePoint. They make total sense and provide for smoother, streamlined user experience. With this post, I would like to explain the options you have in SharePoint to building those kinds of fields on a SharePoint list or library.
What are cascading drop-downs in SharePoint?
Let me first explain what I am talking about. When we work with regular metadata fields and add them as columns to lists and libraries, they work on “select anything” kind of basis. What that means is that if, say we build a column for Car Model (i.e., Toyota, Honda, etc.) and another one for Car Make (i.e., Corolla, Camry, Accord, Civic), the user can select any choice from Column A and any choice from Column B. So how do we build a menu-driven capability, such that when the user selects Toyota from Column A, it only shows models made by Toyota in column B. That’s what this post is all about.
Can cascading drop-downs be built in SharePoint Out of the Box?
The short answer is “No.” Not without custom coding your list or library. So below, I would like to provide all the available alternatives to building cascading drop-downs in SharePoint.
Alternatives to building cascading drop-downs in SharePoint
Option 1: Use Content Types
The closest you can get to cascading, menu-driven drop-downs is by utilizing good-old content types. Using the car example above, you will need to create a content type for each make (i.e., Toyota, Honda, etc.) and a site metadata column for Model (Camry, Accord, etc.). Then respective models will be added to respective content types, such that when the user selects a given Content Type (Make), he/she will be presented with particular models only (for that make).
I documented step by step instructions on how to build content types in this post. With this option, you can only have one level of cascading drop-downs, but I still wanted to present it to you nevertheless. Here are a few screenshots that demonstrate the outcome.
Option 2: Use the Term Store Hierarchy option
The previous option works if you have only one set of drop-down menus on your form for the list or document library. But what if you have a need for multiple cascading menus on the same form. For example, you have to choose make and model and also location, like country/city (where the list of cities changes based on the country chosen). In this scenario, you might benefit from the Term Store option.
One of the key functions of the Term store is the ability to organize metadata into Term hierarchies. Unlike a regular choice column, that only allows for 1 (one) level of labels, you can build hierarchies in the Term Store. So you can have labels, under labels, under labels.
Below is an example of the term hierarchies set up in the Term Store
When the users have to tag an item or a document, they will be presented with a hierarchy of labels. True, this is not a cascading menu, but a very quick and efficient way to mimic one.
By the way, I also recently published a post on how to make some parent labels not selectable – which might make this option even more powerful and user-friendly. Check it out here.
Option 3: Customize in PowerApps
OK, for the real cascading menu, you will need to use Power Apps. It is not something that you can do quickly or easily, like with the options above. You will need to get familiar with Power Apps and some minor coding. Since this falls outside of the “out of the box” solution, I would like to share the technique documented by others who are true experts in this area.
Share Article
