Project: build an incident monitoring dashboard with a map and three indicators

One screen for a stormy night. Picture a heavy storm on a Friday night. Water main breaks are coming in from all over the city, crews are rolling, and the utility director calls with one question: how bad is it right now? Nobody wants to open a spreadsheet, filter it, and add up columns while the phone is ringing. They want one screen that shows where the breaks are, how many are still open, and how many customers have no water. That screen is exactly what you'll build in this lesson. It's the project that ties together everything from this course: the layout, the map element, indicators, arranging, and sharing. By the end you'll have a working incident monitoring dashboard you can show your team on Monday.

What you will learn. Here's what you'll be able to do by the end of this project. First, plan a dashboard starting from the question people actually ask, not from the tools on the menu. Second, build it: a map element and three indicators, all reading from one hosted feature layer of water main breaks. A hosted feature layer is simply a table of places stored in ArcGIS Online, where every row has a location on the map. Third, check that your numbers are right before anyone trusts them, then arrange the elements, fill in the item details, and share the dashboard so the right people can open it without errors.

The project brief. Every good dashboard starts with a short brief. Ours uses one hosted feature layer called Water Main Breaks. Each break has a status field, open or closed, a customers out field with the number of households affected, and a reported date. The director's question becomes three indicators. Indicator one counts the open breaks. Indicator two sums customers out, but only for open breaks, so it shows people who have no water right now. Indicator three compares breaks reported today with breaks reported yesterday. Yesterday's count is a reference, meaning a second number the indicator compares against, so the director can see whether things are getting worse. Write this brief down before you click anything. It keeps you from adding charts that nobody asked for.

The build plan. Here's the whole build as six steps. You prepare the web map first, because the dashboard can only show what the map already has. Then you create the dashboard with a header and theme. Next you add the map element, then the three indicators, then you arrange everything so the map and the numbers sit comfortably together. Finally you save, fill in the item details, and share. Each of these steps is something you practised in an earlier lesson of this course, so nothing here is brand new. The order matters, though. If you share before you've checked the layer's sharing, or style the dashboard before the map is ready, you'll end up redoing work.

Step 1: prepare the web map. Start in Map Viewer and add the Water Main Breaks layer. Style it by the status field, so open breaks are bright red and closed breaks are a soft grey. Your eye should land on the problems first. Then set up the pop-up so clicking a break shows its status, the customers out, and the reported date, and nothing else. Pick a quiet basemap, such as light gray canvas, so the red points stand out. Now save it as a web map with a clear name like Water Main Breaks Operations. This web map is the foundation. Whatever you set here, the symbols, the pop-ups, the basemap, carries straight into the dashboard.

Steps 2 and 3: dashboard, header and map. Now open ArcGIS Dashboards and create a new dashboard. Choose a theme that suits the room it'll be shown in; a dark theme works well on a wall screen in an operations centre. Add a header with a plain title, such as Water Main Breaks, Live, and the utility's logo. Then add a map element and point it at the web map you just saved. In the map element's settings, turn on the legend so viewers know red means open, and layer visibility in case you add a second layer later, such as pressure zones. Keep the default extent on your service area so the map opens where the action is.

Step 4: check the numbers first. Before you configure the indicators, work out on a small sample what they should say. This short Python script builds seven breaks, then does exactly what our three indicators will do. Here a simple day column stands in for the reported date. The script keeps only the open breaks and counts them: four open breaks. It adds up customers out for those open breaks: five hundred fifty five customers. Then it counts today's breaks, four, against yesterday's, three, and works out the percent change, which is the difference divided by yesterday's count, times one hundred. That's plus thirty three percent. Why bother? Because when your indicator shows a number, you now know what it should be. If the dashboard disagrees, a filter is wrong, and you caught it before the director did.

Step 4: configure the three indicators. Now add three indicator elements. For the first, choose the layer, set Value type to Statistic, the statistic to Count, and add a filter where status equals Open. Give it a title like Open breaks. The second is the same, except the statistic is Sum and the field is customers out; keep the Open filter, otherwise closed breaks sneak in. The third counts breaks where the reported date is today. Then open the Reference tab, pick Statistic, and filter the reported date to yesterday. The indicator can now show the percent change in its bottom text. Add conditional formatting so the number turns red when today is higher than yesterday, and the director reads the trend without reading anything.

Steps 5 and 6: arrange, save, share. Let the map take the left side, about two thirds of the width. Then drag the three indicators into one column on the right side, stacked on top of each other. Resize until the numbers are large enough to read from across the room. Save the dashboard, then open its item page and fill in the details: a one line summary, a description of what the layer contains and how often it updates, useful tags like water, breaks, and operations, and a thumbnail. Next, share it with the operations group. Keep it off public unless the data is meant for residents. Finally, open it in a private browser window as another user, and you'll see exactly what your viewers see.

Common mistake: sharing only the dashboard. Here's the mistake that catches almost everyone on their first real dashboard. You share the dashboard with the operations group, send the link, and people open it to find empty indicators, a blank map, or a sign in box. The reason is that a dashboard is only a frame. It points to a web map, and the web map points to the hosted layer, and each of those items has its own sharing setting. If the group can't see the layer, they can't see anything built on it. The fix is simple: share the dashboard, the web map and the layer with the same group. Then always test with an account that isn't yours, because as the owner you see everything.

Recap. Let's recap. First, start from the question people actually ask, how bad is it right now, and turn it into a short brief with the layer, the fields and the numbers you need. Second, build in order: a clean web map, a dashboard with a header and a map element, then three indicators with the right statistic and the right filter, checked against numbers you worked out yourself. Third, arrange the elements so they read from across a room, fill in the item details, and share the dashboard, the web map and the layer with the same group. That's a complete, working operational dashboard, and the same pattern fits outages, service requests or traffic incidents.

Your exercise. Now it's your turn. Pick a different incident layer, such as 311 service requests, power outages, or traffic incidents from your own organisation or from Living Atlas, and build the same kind of dashboard. Write a three line brief first. Then add one map element and three indicators: one count, one sum or average, and one with a reference value that compares today with yesterday or with a fixed target. Before you trust the numbers, work out at least one of them by hand or with a quick script. Finally, share it with a test group and open it as another user. Bring a screenshot to the next lesson.