Maintaining dashboards: copying, swapping data sources and updating safely

Monday Morning, Broken Dashboard. Picture a Monday at a city water utility. The operations manager opens the water main break dashboard for the 8 a.m. briefing, and every indicator, list and chart shows an error. Over the weekend, an analyst fixed a few attributes by deleting the breaks layer and publishing it again. The data is fine and the dashboard is fine, but they no longer point at each other. This is the most common way dashboards fail in real organizations, and it has nothing to do with design. It's about maintenance. In this lesson you'll learn how to copy a dashboard, point it at different data, and change things without breaking what people rely on.

What You Will Learn. By the end of this lesson you'll be able to do three things. First, copy a dashboard so you have a safe draft to experiment on, and know exactly what that copy includes and what it doesn't. Second, swap the data source behind elements, both inside the Dashboards app and, for bigger jobs, by editing the dashboard's settings directly. Third, update the underlying layers and release your changes in a way that keeps the dashboard's link, its embeds in Experience Builder or Hub, and everyone's bookmarks working.

A Dashboard Is a Set of Pointers. To maintain a dashboard well, it helps to know what it actually is. A dashboard item stores no data at all. It stores settings as JSON, which is simply structured text, a bit like a filled-in form. Each element, such as an indicator or a list, holds a pointer to a layer or web map using its item ID. An item ID is the unique code ArcGIS Online gives every item, like the serial number on a water meter. So when you delete a layer and publish it again, you get a brand new serial number, even though the name looks identical. The dashboard is still looking for the old one.

Copying a Dashboard. The simplest maintenance tool is the copy. In the dashboard editor, open the Save menu and choose Save As. You get a new dashboard item with its own ID and URL. Two details matter here. First, only the dashboard is copied. The layers and web maps behind it are not, so your draft still reads and displays the live service request or outage data. Second, sharing doesn't carry over. The copy starts private, which is exactly what you want for a draft. Name it clearly, for example Water Breaks Dashboard DRAFT, so nobody mistakes it for the real thing.

Swapping Data in the App. Now suppose you built the dashboard against a test layer and want to point it at the production layer. In the editor, open an element, go to its Data tab and choose a different layer. The element keeps its settings, but only if the fields it uses exist in the new layer with the same names and types. If your indicator counts rows where status equals Open, the new layer needs a status field with that value. After each swap, click through filters and actions between elements, because a list that filters a map depends on both sides matching. For three elements this is fine. For thirty, there's a faster way.

Worked Example: Swap Every Reference. Here's a small version of what a dashboard's JSON looks like. Three widgets, two reading the test breaks layer and one reading a crews layer. We turn the settings into text, count how many times the old item ID appears, then replace it with the production ID and read it back. The output shows two references swapped, while the crews chart stays untouched. In real life you'd fetch the dashboard's JSON with the ArcGIS API for Python or with ArcGIS Assistant, a free Esri web tool for viewing and editing an item's JSON. Save a backup copy first, make this swap, and write it back to the item. One run updates every element at once. This only works if the production layer has the same fields and layer number as the test layer, just like the swap in the app.

Updating Layers Without Breaking Links. Most dashboard breakages start with the data, not the dashboard. When a layer needs new data, you have safer options than starting over. Overwrite replaces the contents of a hosted feature layer but keeps the same item. Append adds new rows or updates matching ones, which suits a nightly load of service requests. Plain editing fixes values in place. All three keep the item ID, so every dashboard, web map and Hub page that uses the layer keeps working. Keeping the ID is only half the job: field names and types must stay the same too, which we come back to shortly. Deleting and republishing is the one route that gives you a new ID and breaks all of them.

A Safe Release Workflow. Put it together into a routine. Save a private draft, make your changes there, and test on desktop and on a phone, because field crews see the mobile layout. When it's right, don't share the draft as the new dashboard. Instead, copy the draft's JSON settings into the original item, with the ArcGIS API for Python or ArcGIS Assistant, after saving a backup. That way the original keeps its item ID and URL, so the embed in your Experience Builder app, the link on the Hub site, and the bookmark on the storm desk all show the new version. Why go to that trouble? Because nobody has to hunt for a new link during an incident. Finally, send users a short note on what changed.

Protect What Is Live. A few habits protect the production version. In each item's settings, turn on delete protection for the dashboard and every layer it depends on, so nobody removes them by accident. Keep a dated backup of the dashboard JSON before each change, so you can roll back in a minute. In the item description, write which layers it uses, who owns it, and who to call when it breaks. And name things plainly, with PROD and DRAFT in the titles. During storm response, the person fixing the dashboard at midnight may not be you, and these notes are how they succeed.

Common Mistake: Changing the Schema. The classic mistake is changing the schema, meaning the list of fields, their names and their types, without checking who depends on it. Someone renames status to break status for clarity, or changes a date field to text, and every indicator, filter and chart built on that field stops working. And republishing from a new file gives the layer a new ID, which breaks everything at once. The fix is a habit. Before you change a layer, check the dashboards and apps that use it. If a field really must change, add the new field alongside the old one, update the dashboard in a draft, release it, and only then retire the old field.

Recap. Let's recap. A dashboard is a set of pointers: it stores settings and item IDs, not data, so keeping those IDs stable is what keeps it alive. To work safely, copy with Save As, swap data sources element by element in the app, or all at once in the JSON with a backup in hand. And when data changes, overwrite, append or edit in place, protect live items from deletion, and never delete and republish a layer that others depend on.

Exercise. Here's your task before the next lesson. Take one of your dashboards, such as the service requests or outages dashboard from earlier, and use Save As to make a private draft. In the draft, point one element at a different layer that has matching fields, for example a copy of your own layer made with Save As on the layer, or a filtered view of it. Note what kept working and what needed fixing. Then go to the original dashboard and its layers, turn on delete protection, and write the data sources and owner into the description. You'll use this draft habit in the storm response project.