Table element: feature tables and grouped tables for detailed records

The storm night spreadsheet problem. Picture a storm response night. Your outage map shows 140 red points, and it looks great on the big screen. Then the operations supervisor walks over and asks a simple question. Which outages have been open longest, which crew has each one, and how many customers are waiting? You can't answer that by clicking dots one at a time. People who run the response need records they can read, sort and act on, laid out in rows. That's exactly what the table element in ArcGIS Dashboards gives you. It shows the detail behind the map, and it can also roll the detail up into totals by category.

What you will learn. By the end of this lesson you'll be able to do three things. First, build a feature table that shows the right fields in the right order, sorted so the urgent records come first. Second, use formatting so a late service request or a long outage stands out without anyone having to read every number. Third, build a grouped values table that turns hundreds of individual records into a short summary, such as the number of requests by type and the average days they stay open. We'll work with service requests and utility outages throughout, and we'll check the numbers along the way.

Two kinds of table. When you add a table element to a dashboard, you choose between two types. A feature table shows one row per feature. If your layer holds water main breaks, each break becomes a row with its address, date, pipe material and repair status. A grouped values table works differently. You pick a field to group by, such as request type, and each category becomes one row with statistics next to it. A statistic here just means a single number that sums up many records, like a count, a total or an average. Think of the feature table as the pile of work orders and the grouped table as the tally sheet on top.

Setting up a feature table. Setting up a feature table follows a short path. Start by choosing the layer, then add a filter so the table only holds what matters, such as outages with a status of open. Next, pick the columns. Resist the urge to show every field. A supervisor needs the outage ID, district, crew, start time and customers affected, not the internal object ID or the edit tracking fields. Put the columns in reading order, most important on the left. Then choose the sort field. For outages, sorting by start time with the oldest first puts the longest-waiting customers at the top. Finally, set the maximum number of features the table loads.

Formatting rows that need attention. Plain rows are hard to scan, so use formatting. Each column has number and date formats, and you can set how many decimals to show and whether dates include the time. For rules, turn on advanced formatting, which uses Arcade, the short expression language built into ArcGIS. This snippet checks each record. If the request has been open more than seven days, the days open cell gets a light red background and dark red text. Everything else stays neutral. Keep the rule to one clear meaning, like "late", and use the same color for it on the map and in the table, so people learn it once.

Tables that drive the map. A table is most useful when it's connected to the rest of the dashboard. In the table's actions settings, you can make a row selection zoom or pan the map to that feature, so clicking an outage row flies the map straight to it. A selection can also filter other elements, for example narrowing a crew chart to the district you picked. It works the other way too. A category selector for district, or a click on a chart bar, can filter the table. Now the supervisor clicks the oldest outage, sees where it is, and sees the crew assigned, all in one move.

Building a grouped values table. Now switch to the grouped values table. You choose a field to group by, like request type in a 311 service request layer. Then you add one or more statistic columns. Count tells you how many records fall in each group. Sum adds up a numeric field, such as customers affected. Average, also called the mean, adds the values and divides by how many there are, so it gives the typical value for that group. Minimum and maximum show the extremes. Finally, sort by one of those statistics, so the busiest or slowest category sits at the top of the table.

Worked example: requests by type. Let's work through a real example with eight service requests. Each has a type and a days count: how long it took to close, or for a request that is still open, how long it has waited so far. A grouped values table does the same job as this SQL. SQL is the standard language for asking questions of a database table, and here it's written as a query so you can see each step. Grouping by type makes every request of the same kind collapse into one row. Potholes have four requests with an average of three days. Streetlights have two, averaging six and a half days. Graffiti has two, averaging one and a half. Sorting puts the busiest type first. Notice anything? The final grouped table ranks potholes top by volume, but streetlight requests take the longest on average.

Check the numbers before you publish. Before you put a summary in front of executives, check it against the raw data once. If you or an analyst on your team uses Python, this is a quick way. We build the same eight requests in pandas, a popular Python library for working with tables. We group by type, then ask for the count and the mean of days, sorted the same way as the dashboard. In the output, look at two columns. The count column reads four, two, two. The mean column reads three, six point five and one point five. That matches the grouped table exactly: four potholes averaging three days, two streetlights averaging six and a half, two graffiti requests averaging one and a half. When both agree, you can trust the dashboard.

Common mistake: silently cut-off rows. Here's the trap that catches many teams. The maximum features setting limits how many rows the table loads, which keeps it fast. But the table doesn't warn anyone that rows were dropped. Say you cap a water main break table at fifty rows and sort by break ID. During a big freeze you have two hundred breaks, and the oldest unrepaired ones may never appear. The fix is simple. Sort by what matters most, such as days open, longest first, before you set the cap. Also add an indicator showing the total count, so nobody mistakes fifty rows for the whole picture.

Recap. Let's recap. The table element comes in two types. A feature table shows every record, one row each, and a grouped values table rolls records up by category with statistics like count, sum and average. Make any table useful by picking only the columns people need, sorting so urgent records come first, and formatting so late or critical rows stand out at a glance. Connect it to the map with actions so a click takes people straight to the location. And before you publish, check the summary numbers against the raw data and make sure the maximum features cap isn't hiding anything important.

Your exercise. Now it's your turn. Open a dashboard with a service request or outage layer, either from Living Atlas, Esri's free library of ready-made map layers, or from your own organization. Add a feature table with up to five columns, sorted so the oldest open records sit at the top, and use a formatting rule to highlight anything open longer than seven days. Then add a grouped values table that shows the count and the average days open for each request type. Finally, set a row click on the feature table to zoom the map. In the next lesson, you'll bring all of this together in a full service request performance dashboard.