Sharing securely: groups, organization and public access

The link that went wrong. Picture a storm night at a regional utility. The operations team has built a solid outage dashboard, and at ten pm the manager sends the link to city council members. They open it and see gauges showing zero and a blank map. Meanwhile, a second copy meant for the public website is showing customer names and account numbers in a table. Nobody changed the design. Both problems came from the same place: who was allowed to see which item. In this lesson we fix that for good, so the right people see everything they need and nobody sees more than they should.

What you will learn. Here's the plan for this lesson. First, you'll learn the four sharing levels in ArcGIS Online and when each one fits, from a private draft to a fully public page. Second, you'll learn the sharing chain, which explains why a dashboard can be shared correctly and still show nothing. Third, you'll learn how to put a dashboard in front of the public without exposing sensitive data, using a tool called a hosted feature layer view. By the end, you'll be able to audit any dashboard's sharing in a few minutes.

Four sharing levels. Every item in ArcGIS Online, whether it's a dashboard, a web map or a layer, has one sharing level. Owner only means just you, and admins, can see it. That's right for drafts and for raw source data. Groups means only members of the groups you pick, like a Storm Ops team. Organization means anyone who signs in to your org, which is fine for internal dashboards staff everywhere should see. Everyone means public: anyone with the link, no sign-in at all. Think of it like a building. Your desk, a locked meeting room, the staff floor, and the lobby open to the street.

Groups do the real work. Groups are where most secure sharing actually happens. Create one group per audience, for example Storm Ops for the control room, Council Briefing for elected officials, and Field Crews for mobile users. Then share items to groups, and manage access by adding or removing members. When a contractor leaves after storm season, you remove them from one group instead of hunting through fifty items. Watch the group settings too. Set membership to invitation only, and keep the group itself hidden from people outside it. A shared update group lets members edit each other's items, so keep that for your authors, never for viewers.

The sharing chain. Now the council's blank map makes sense. A dashboard doesn't hold data. It points to a web map, and the web map points to layers, and some indicators point straight at layers too. Each of those items has its own sharing level. A viewer needs access to every piece they're meant to see. If the dashboard is shared with the Council group but the outages layer is still owner only, council members get empty gauges. The good news is that when you share a dashboard, ArcGIS Online offers to update the sharing of dependent items you own. Read that prompt carefully, though, because it can widen access to layers you meant to keep private.

Public, but safe: layer views. So how do you publish outages to the public without customer names? You use a hosted feature layer view. A view is a second window onto the same data, with its own settings, a bit like a report that shows selected columns from a spreadsheet without copying it. You keep the source layer off public sharing, shared only with your internal groups, because crews edit it all night. Then you create a view that shows only the outage area, status and estimated restore time, and hides account numbers and addresses. You can also filter rows, for example only confirmed outages. Share the view publicly, build the public map on it, and the data stays live with no copying.

Worked example: storm response. Let's put it together for a storm response. The source outages layer is shared only with the Storm Ops and Field Crews groups, with editing turned on so crews can update it, and it is never shared with the organization or with everyone. The internal dashboard goes to the Storm Ops group and shows everything: crew locations, customer counts, work order numbers. The council dashboard goes to the Council group and is built on a second view that keeps only the district, status and customers-affected fields, with no customer names or account numbers. The council dashboard's charts then total those numbers by district, and even if council members query the view directly, there is no customer detail in it to find. The public dashboard is shared with everyone and built only on the public view we just made. Three audiences, one live dataset, and each audience sees exactly its slice. Sketch this layout for your own team, it takes five minutes on paper.

Audit the chain with Python. Here's a small audit you can run before any storm season. We give each sharing level a rank, from private at zero up to public at three. Then we list what each item uses, and flag any part that is shared more narrowly than the item using it. In real life you'd fill these dictionaries with the ArcGIS API for Python, but the logic is the same. So what does it find? The public Storm Map uses Crew Locations, which is only shared with the organization. Public viewers will silently get a map without crews. Crew locations should not be public anyway, so the fix is to remove that layer from the public map, not to share it wider.

Settings to check before going public. Before you click share with everyone, walk through four settings. First, make sure editing is off on every public layer or view, so nobody on the internet can add fake outages. Second, turn off allow others to export data, otherwise anyone can download the full table as a file. Third, turn on delete protection for the source layer and the dashboard, so an accidental click during a busy night can't remove them. Fourth, check your organization's settings with your administrator. Many organizations limit public sharing to a few trusted roles, which is a sensible safety net.

Common mistake: sharing the source. The most common mistake is sharing the editable source layer itself with everyone, and then hiding sensitive fields in the pop-up or the dashboard table. That feels safe, but it isn't. Hiding a field in a pop-up only changes what's displayed. The field is still in the layer, and anyone who finds the layer's web address can query it directly and read every value. The fix is simple. Keep the source private, create a view, remove the sensitive fields from the view's definition, and share only the view. What isn't in the view can't leak.

Recap. Let's recap. ArcGIS Online has four sharing levels, and groups are the practical way to control who sees what for each audience. A dashboard depends on a chain of web maps and layers, and viewers need access to every link they're meant to see, so check the chain whenever something looks empty. And when a dashboard goes public, build it on a filtered, read-only hosted feature layer view, with exports off and delete protection on, while the editable source stays private. With those three habits, both of the storm night problems from the start simply don't happen.

Your exercise. Now it's your turn. Pick one dashboard you own, perhaps a service request or water main break dashboard. Open its item page and list every web map and layer it uses, along with each one's sharing level. Mark any gap where a part is shared more narrowly than the dashboard, and decide whether that gap is intended or a bug. Then write a short plan for a public version: which fields would the view keep, which rows would it filter, and which settings would you turn off. Bring that plan to the next lesson, where we'll design for phones and field crews.