Project: executive KPI dashboard for a utility's outage response

The 2 a.m. phone call. Picture a spring storm rolling through your service area at midnight. Trees are down, feeders are tripping, and by two in the morning the CEO is on the phone. She has two questions: how many customers are out right now, and how fast are we getting them back? If the answer means someone digs through the outage management system and pastes numbers into an email, you've already lost twenty minutes. In a real event, those twenty minutes cost the utility its credibility with the mayor and the press. The answer should already be on one screen, and today you build that screen. This project brings the whole course together. You'll build an executive KPI dashboard for outage response that answers those questions at a glance, with the correct numbers and clear colors, on any screen.

What you will learn. By the end of this lesson you'll be able to do three things. First, you'll turn the vague questions executives ask into a short, precise list of KPIs. A KPI, or key performance indicator, is one number that tells you whether things are going well, like the fuel gauge in your car. Second, you'll feed those KPIs from an Arcade data expression that combines and reshapes your layers, so every element reads the same clean table. Third, you'll lay out, color and tune the dashboard so an executive can read it in five seconds and it still loads quickly during a storm.

From questions to KPIs. Start with the questions, not the widgets. Sit down with the operations director and write down what leadership asks during every event. For our utility that gives four KPIs. Customers out right now, because customers are what the public and regulators count. The share of affected customers who have been restored, which shows momentum. The number of active outages, plus how long the oldest one has been open, in hours, because a long-running outage turns into a news story. And customers out by district, colored by severity, so leaders can see where to send crews. Keep the list this short. Every extra number you add makes the important ones harder to find.

The data flow. Here's the data flow behind the dashboard. The outage layer from your outage management system has one point per outage. Each point carries the number of customers affected, a status of active or restored, and a start time. A second layer holds your service areas, with the total number of customers served in each district. An Arcade data expression reads both layers, filters them, and groups the results into one tidy table per district. Aggregating means rolling many rows up into one number, the way a timesheet adds up hours for each person. The indicators, the district chart and the list all read that same table, so the numbers on screen always agree with each other. The map shows the outage layer directly.

Worked example: the KPI math. Before building anything, check the math on a small sample. Each row is one outage: district, customers affected, status, and hours open. Three outages are active, affecting twelve hundred, eight hundred and four hundred customers, so twenty four hundred customers are out right now. Restored outages cover twenty nine hundred and fifty customers. The percent restored is restored divided by everyone affected in this event, which comes to about fifty five point one percent. The oldest active outage has been open five and a half hours. When the dashboard shows these same numbers for this same data, you know your expression is right. Keep a test set like this and check it again every time you change the dashboard.

The data expression in Arcade. Here's the same idea as an Arcade data expression. FeatureSetByPortalItem opens the outage layer by its item ID. Replace OUTAGES ITEM ID with the item ID of your own outage layer. You ask only for the three fields you need, and you pass false for geometry, because shapes add weight and the KPIs never use them. Filter keeps the active outages, using a SQL where clause. GroupBy then rolls them up into one row per district, with a field called cust out that holds the sum of customers affected. That's the whole engine: a few lines replace a nightly spreadsheet export. In the full project you'd add a second FeatureSet for the service areas and attach customers served to each district, so every row can also carry its percent out.

Coloring districts by thresholds. Now let's turn those numbers into colors. Here are four districts, with customers out and customers served. First, divide out by served to get the share of customers without power. Fill that down the column. Now the threshold rule: ten percent or more is red, two percent or more is amber, and anything lower is green. Copy the rule to every district. North lands at thirteen point three percent, so it shows red. East is amber at four percent, and South and West stay green. In the dashboard, you write the same rule in the list's advanced formatting and return the color as a background color. Agree on the thresholds with your operations lead before the storm, not during it.

Layout and visual hierarchy. Next, lay it out in ArcGIS Dashboards. Visual hierarchy means the most important thing is also the biggest and comes first, like a newspaper front page. So the top row holds the four indicators, with large numbers, thousands separators, and no decimals except on the percent. In the middle, put the map of active outages next to the district list with its red, amber and green colors. At the bottom, a serial chart shows customers out over time, which answers the question, are we getting better. Add a small rich text element showing when the data was last updated. An executive who can't tell how fresh a number is will stop trusting the whole screen.

Keep it fast during the storm. A dashboard that stalls during the storm is worse than none at all, because people go back to phone calls. Use statistic indicators, so the server does the counting and sends back one number instead of thousands of points. Set the layer's refresh interval to a minute or two. Refreshing every few seconds just piles extra load on the service when traffic is already at its peak. Remember the query limits from earlier in this course: a list pulling raw features can quietly stop at the maximum record count. So how do you know it will hold up? Copy the outage layer, load it with storm-sized data, say five thousand outages, and time how long the dashboard takes to load.

Common mistake: counting the wrong thing. The most common mistake in this project is counting the wrong thing. A count indicator on the outage layer shows how many outage records there are, not how many customers are dark. One feeder fault can leave three thousand homes without power, while fifty small single-transformer outages may add up to only two hundred. If you count outages, the screen tells the CEO things are improving just as the big one gets worse. Always sum the customers affected field. The same trap applies to percent restored: the denominator, the number you divide by, must be everyone affected in this event, not only the outages still open. Finally, label every indicator with its unit, customers or outages, so nobody has to guess.

Recap. Let's recap. First, start from the questions leadership actually asks, and keep the KPIs few and based on customers rather than outage records. Second, build one Arcade data expression that filters and groups your layers, and let every indicator, chart and list read from it, so the numbers always match. Third, make the dashboard readable and fast: put the biggest numbers at the top, use agreed red, amber and green thresholds, show when the data was last updated, and let the server do the aggregation with a sensible refresh interval. With that in place, the two a.m. phone call becomes a link you share.

Your exercise. Now it's your turn. In your ArcGIS Online organization, create a sample outage layer with at least twenty points. Give each point a district, customers affected, a status and a start time. Then build the dashboard from this lesson: four indicators on top, the district list colored by the ten percent and two percent thresholds, a map of active outages, and a serial chart of customers out over time. Feed the district list from an Arcade data expression that uses Filter and GroupBy. Finally, check the dashboard against a quick total in Python or a spreadsheet, just like we did today. If the numbers match, take a screenshot and bring it to the next lesson.