Category selectors: filtering by field values with dropdowns and buttons

One click, the whole screen answers. It's the morning after a big storm. Your city's service request dashboard shows twelve hundred open requests on one map, and the emergency operations manager asks a simple question: how many downed trees are still waiting in the South district? Right now, someone has to squint at the map or export a spreadsheet to find out. What if the manager could click a button labeled Downed tree and watch every map, chart and number on the screen update together? That's what a category selector does. It's one of the fastest ways to turn a static wall of data into a tool people actually use during an incident.

What you will learn. In this lesson you'll do three things. First, you'll learn where a category selector gets its list of choices: grouped from a field's values, one per feature, or from values you type. Second, you'll pick the right presentation, which can be a dropdown, a button bar or radio buttons, and you'll decide between single and multiple selection. Third, you'll connect the selector to other elements with filter actions, so the map, charts and indicators all respond to one click. We'll use a small storm response dataset of service requests the whole way through, so every step has something concrete to look at.

What a category selector is. A category selector is an element in ArcGIS Dashboards that is most often placed in the dashboard's header or side panel, where it stays visible. It shows a list of choices built from a field in your layer, like request type or district. When someone picks a choice, the selector sends a filter to the elements you've connected. A filter here just means a condition, such as type equals Downed tree, that hides every row that doesn't match. Think of the filter buttons on a shopping site. You click Shoes, and the whole page shows only shoes.

Three sources of categories. When you add a category selector, the first setting is where the categories come from, and there are three options. Grouped values scans a field and makes one choice per distinct value, so a new request type appears automatically when it shows up in the data. If the field has a domain, the choices show its readable descriptions instead of raw codes. Features makes one choice per feature, meaning per row, so on our storm layer you would get twelve hundred choices. Keep it for short lists of named items, like a handful of facilities. Static values means you type the list yourself, each with its own condition, which is handy for something like High priority meaning priority is one or two. For most operational data, Grouped values is the safe default.

How grouped values become choices. So what does the Grouped values source actually do behind the scenes? Here's the requests table from our storm dataset: eight service requests, each with a type and a district. The grouping query collects rows with the same type into one bucket and counts them. Downed tree has three requests, flooding and power line have two each, and debris has one. Sorting by count puts the biggest group first, so Downed tree sits at the top. Those four rows become the button labels or dropdown entries, and you can even show the count next to each one.

Dropdown, buttons, single or multiple. Next, choose how the choices look. A dropdown fits long lists, say thirty districts or fifty request types, because it takes almost no space. A button bar puts every choice on screen, which is perfect for up to about six categories on a wall display where nobody wants to open a menu. Radio buttons sit in between: every choice stays visible, but in a compact vertical list that fits a side panel. Then decide the selection mode. Single selection means one category at a time, while multiple selection lets someone compare, for example Downed tree and Power line together. A good rule of thumb is a button bar for up to about six choices and a dropdown for anything more.

Wiring the filter action. The selector does nothing until you wire it up. In the selector's Actions tab you add a filter action and tick each target element: the map layer, the serial chart, which is the bar or line chart element, and the indicator. For every target, you pair the selector's field with the matching field in that element's data source. This matters when targets use different layers. Your requests layer might call the field type, while a crew assignments layer calls it request category. Dashboards needs you to pair them explicitly, otherwise that element won't respond to the selection.

Worked example: the filter in code. Let's make the filter logic concrete with a few lines of pandas, which run the same condition a dashboard applies. The apply selector function returns everything when nothing is chosen, and otherwise keeps only rows whose type is in the chosen list. With no selection, we see all eight requests. Pick Downed tree and we get three, two of them in the South district, which answers the manager's question straight away. Pick Downed tree and Flooding together, a multiple selection, and the count becomes five. That's exactly what the indicator on your dashboard would show.

Defaults, the None option and placement. A few settings decide how the selector behaves when the dashboard first opens. You can add a None option, often labeled All, so people can clear the filter with one click instead of hunting for a reset. You can set a default selection, for example opening the tree crews' screen already showing Downed tree. And where should it sit? Selectors can also go in the dashboard body, but a header or side panel keeps them visible while people scroll. Give each one a clear label like Request type rather than a generic name. Small details like these decide whether operators trust what they're seeing.

Common mistake: one element left out. Here's the mistake that causes real confusion in operations rooms. Someone wires the selector to the map and the chart, but forgets the indicator at the top. The manager clicks Downed tree, and in our eight-request example the map shows three points while the big number still says eight. People start quoting the wrong figure on the incident call. The fix is simple: after wiring actions, click every choice and check that every element changes. If one element should deliberately stay unfiltered, like a citywide total, label it clearly, for example All requests, citywide, so nobody mistakes it for the filtered count.

Recap. Let's recap. A category selector turns a field in your layer into clickable choices, and the Grouped values source keeps that list current as new values arrive. Pick the look that fits the list, a button bar for a handful of choices and a dropdown for long lists, and choose single or multiple selection based on whether people need to compare. Finally, a selector only works through its filter actions, so connect every relevant element, match fields across layers, and test each choice before you share the dashboard.

Exercise: add your first category selector. Now it's your turn. Open a dashboard you built earlier in this course, or create a new one from a service request or outage layer, using your own data or a Living Atlas layer. Add a category selector to the header with the Grouped values source on a type or status field. Use a button bar if there are six or fewer values and a dropdown otherwise, and add a None option labeled All. Connect it to the map, one chart and one indicator. Then click through every choice and write down one count per category. Next lesson, we'll add number and date selectors for time windows.