Project: emergency operations dashboard for storm response on desktop and mobile

Storm night at the EOC. It's eleven at night and a storm is moving across the county. Power is out in three districts, service requests about fallen trees are pouring in, and two main roads are closed. In the emergency operations center, or EOC, the incident commander asks one question: where are we right now? Out in a truck, a line crew lead asks the same question on a phone with one bar of signal. And residents want to know when their lights come back. In this project you'll build dashboards on one shared set of data that answer all three, using everything from this course.

What you will build. By the end of this lesson you'll have three things. First, a data plan: which layers feed the dashboards, and which filtered layer views sit in front of them. Second, two dashboards built on the same views: a wide one for the EOC wall screen and a narrow, phone-sized one for field crews. Third, a publishing plan: who can see what, how the dashboards perform under load, and how a public version lives on a Hub site or Experience Builder page without exposing crew details. Treat this as a dress rehearsal for a real event.

The data plan. Start with data, not widgets. Your organization owns four hosted feature layers: outages, service requests, road closures and shelters. From Living Atlas you add context, such as active weather warnings and a radar layer. Then, instead of pointing every dashboard at the full layers, you create hosted feature layer views. A view is like a window cut into the same data: it shows only certain rows and certain fields, but it's always live. One view keeps only active outages for the EOC and crews. Another public view drops crew names, phone numbers and internal notes. The diagram shows the outages layer, but each of the four source layers gets the same pair of views.

Desktop layout for the EOC. Now open ArcGIS Dashboards and build the desktop layout. Put the map in the middle, with active outages, road closures and shelters. Across the top, place three indicators: the number of active outages, the total customers out, and the share of customers already restored. On the right, a serial chart shows outages by district, and a list shows the ten largest outages. Add a category selector for district in the header, and set its actions to filter the map, the chart and the list together. Now a single click answers the commander's question for one district.

Worked example: the indicator numbers. Let's check what those indicators should show, using six sample outages. The first indicator counts features where status equals active, which is a filter plus a count. The second is a sum: add up the customers field over active outages only, 1200 plus 3100 plus 800 plus 1500, which gives 6600. The third is a ratio: restored customers divided by all customers, times one hundred. Here 450 plus 260 is 710 restored, out of 7310 in total, so about 9.7 percent. The last line groups by district, which is exactly what the serial chart does. Running this against a small sample is a quick way to confirm your indicator settings before the storm arrives.

Mobile layout for field crews. Crews don't need the wall screen. ArcGIS Dashboards is responsive and stacks elements on a small screen, but a busy desktop dashboard becomes a long scroll on a phone. So build a second, phone-sized dashboard that reads from the same views, with everything in one column. Put the customers out indicator first, then the map, then the outage list. Leave out the serial chart, because charts that rely on hovering don't work well with a thumb. Set the list's action so tapping an outage zooms the map to it. What does a crew lead really need at a glance? Usually just where the next job is and how many people it affects, so keep it that short.

Performance under storm load. During a storm, dozens of people open these dashboards at once while the layers are being edited. Each element sends its own queries, so every extra element adds load. Point everything at the active-only view, so the server skips thousands of old restored outages. Cap the list at the ten largest outages, and keep the chart to one bar per district rather than one per outage. Remove any element nobody looks at. Then set the refresh interval to about one minute. You set it on the map layer or the data source, not on the dashboard as a whole. A refresh every few seconds across fifty viewers can slow the service for everyone, including the crews editing it.

Sharing and the public page. Now publish. Share the EOC dashboard, the crew phone dashboard and the active-only view with two groups: the EOC group and the field crew group. Nobody else in the organization needs them. For residents, build a simple page in Experience Builder or a Hub site with a map and two indicators, both reading from the public view, and share only those items publicly. Remember that a dashboard is just a container: every map and layer inside it has its own sharing setting, and viewers must be able to see each one.

Common mistake: sharing the full layer publicly. Here's the trap that catches teams under pressure. Someone makes the public page work quickly by sharing the original outages layer with everyone. The page looks fine, because the pop-ups hide the sensitive fields. But anyone who opens the layer's web address can query every field, including crew names, phone numbers and internal notes. Pop-up settings are not security. The fix is to share only the public view with everyone, keep the source layer and the internal views in groups, and check each item's sharing before the storm, not during it.

Recap. Let's pull it together. First, design the data before the widgets: keep your source layers private and put filtered layer views in front of them for each audience. Second, build two dashboards on the same views: a rich desktop one for the EOC and a short, thumb-friendly phone one for crews. Third, operate it like a service: point elements at filtered views, limit queries and refresh sensibly, share by group, and give the public their own page backed only by a public view. That's a setup ready for a real storm.

Your exercise. Before the next lesson, build this project yourself. Create a small outages layer with ten sample points and a road closures layer, and, if you like, add a Living Atlas weather layer for context. Make an active-only view and a public view with the sensitive fields removed. Build the desktop dashboard with indicators, a map, a chart, a list and a district selector. Then build a phone-sized dashboard on the same views and open it on your own phone. Finally, ask a colleague to open the public page while signed out, and confirm they can't reach any internal field.