Saving, sharing and filling in item details for a dashboard

The link that did not work. Picture a storm night. You've spent the evening building a power outage dashboard, with a map of affected circuits and indicators for customers out and crews assigned. At midnight you email the link to the incident commander and go to bed. At six in the morning your phone rings. They clicked the link and got a sign-in wall, or a blank map. Nothing was wrong with the dashboard itself. It was saved, it worked on your screen, but it was never shared properly, and the data behind it wasn't either. This lesson is about that last mile: saving, describing and sharing a dashboard so the right people can actually open it.

What you will learn. By the end of this lesson you'll be able to do three things. First, save a dashboard and understand where it lives once it's saved, because in ArcGIS Online a dashboard is an item, just like a web map or a feature layer. Second, fill in the item details: the title, summary, tags, thumbnail and description that help people find your dashboard and decide whether to trust it. Third, share the dashboard and everything it depends on at the right level, so your field crews see it and the public doesn't see what they shouldn't.

Saving your work. Saving is simple, but it's worth being deliberate about. The Save button in the dashboard toolbar keeps your changes to the dashboard you're editing. Save as creates a brand new copy with its own title, which is handy when you want a variant, say a public version of an internal service request dashboard. Save as works like photocopying a form before you mark it up: the original stays untouched. If you close the browser tab with unsaved changes, those changes are gone, so save after each meaningful step, like adding the map or finishing a row of indicators.

A dashboard is an item. Once saved, your dashboard shows up in My Content as an item. An item is ArcGIS Online's word for any saved thing with its own page, owner and sharing settings. Open the item page and you'll find an Overview tab, where the descriptive details live, and a Settings tab, which has options like delete protection. This is also where you share. Keep one idea in mind for later: the dashboard item doesn't hold the data itself. It points to a web map, and that web map points to feature layers, and each of those is a separate item with its own sharing.

Item details that matter. Item details are the label on the jar. Without them, nobody knows what's inside or whether it's fresh. The title should be plain and specific, like Water Main Breaks, Live Operations, not Dashboard Copy Two. The summary is one sentence saying what the dashboard shows and for whom. Tags are the words colleagues will type into search, such as water, breaks, operations. The thumbnail is the small picture shown in galleries and search results. The description is where you note the data sources, how often the layers update, and who to contact when something looks wrong.

Worked example: before and after. Let's look at one real item page, before and after. Before, the item is called Dashboard Copy Two, with no summary, no tags and an empty description. Nobody searching for water breaks would find it, and anyone who stumbled on it couldn't tell whether it was current. After, the title reads Water Main Breaks, Live Operations. The summary says it shows open breaks and crews by district. The tags are water, breaks and operations, and the description says the layers update every five minutes and names who to contact. That's four of the five details done well. Now run down the checklist, and one gap remains: the thumbnail is still the blank default. That's very common, because the thumbnail is the easiest one to forget. On the item page, choose to edit the thumbnail and upload a screenshot of the dashboard before you share it.

Sharing levels. Every item has a sharing level. Owner means only you can see it, and that's the default when you first save. Groups lets you share with specific teams, for example a Utility Operations group or a Storm Response group. Organization means anyone signed in to your ArcGIS Online organization can open it. Everyone makes it public, so anyone with the link can view it without signing in. So which level fits an internal outage dashboard for the control room? Usually a group, because it reaches exactly the people who need it and nobody else.

The chain behind the dashboard. Let's follow one viewer through what happens when they click your link. They open the dashboard item first. But behind it sit a web map and an outages feature layer, and each is its own item. Now trace the request: the dashboard loads the web map, the web map queries the layer, the layer returns its features, and only then does the map draw. If any item in that chain is shared at a narrower level than the dashboard, the viewer hits a wall at that step. That's exactly what happened to our incident commander.

Sharing it the right way. Here's the routine for a storm response dashboard. Open its item page, choose Share, and tick the Storm Response group. When the web map or layers are shared more narrowly, ArcGIS Online usually offers to update them to match, and you can accept that. You can also share the web map and layers yourself first, which makes you check each one on purpose. Then test it the way a viewer would: ask a colleague in that group to open the link. Testing it yourself doesn't count, because signed in as the owner you see everything. A private browser window only helps for a dashboard shared with Everyone. For a group share it just shows a sign-in wall. A thirty second test saves a six a.m. phone call.

Common mistake: oversharing the data. The opposite mistake is quieter and worse. You make a service request dashboard public, accept the prompt, and now the underlying layer is public too, including the caller's name, address and phone number. Your dashboard may only show a count, but anyone can open the layer directly and read every field. Hiding a field in a widget doesn't protect it. The fix is a hosted feature layer view, a filtered window onto the same data that exposes only safe fields, such as request type and status. Share that view publicly and keep the original private. One caution: a view still places every point exactly where it is, and a caller's exact point is effectively their address. For sensitive points, publish a separate layer that is aggregated or generalized, for example counts by district.

Recap. Let's pull it together. A saved dashboard is an item in My Content, with an item page where you edit details and set sharing. Good item details, a clear title, a one sentence summary, searchable tags, a thumbnail and an honest description, help people find the dashboard and trust it. And sharing is about the whole chain: the dashboard, the web map and the layers must all be shared at the right level, wide enough that viewers can open them, but never wider than the data should go. When in doubt, share a view layer.

Your exercise. Before the next lesson, take a dashboard you built earlier, for example the traffic incidents or water main breaks one, and make it ready for others. Open its item page and fill in a specific title, a one sentence summary, at least three tags, a thumbnail and a short description with the data source and update rate. Then share it with one group, accept or make the updates to its web map and layers, and check that no layer carries fields that group shouldn't see. Finally, ask a colleague in that group to open the link and confirm the map draws for them.