Hosted feature layer views: filtered data for each audience

One layer, many audiences. Picture a Tuesday morning. A twelve inch water main breaks on Oak Street, and the city wants residents to see it on a public map right away. But the layer your crews edit also holds crew assignments, internal notes and the addresses of the customers who called it in. If you share that layer publicly, all of that goes out with it. If you copy it into a second layer, you now maintain two versions that drift apart by lunchtime. So how do you give every audience exactly what it needs from one source of truth? That's the job of hosted feature layer views, and it's the topic of this lesson.

What you will learn. By the end of this lesson you'll be able to do three things. First, explain what a hosted feature layer view is, and why it's not a copy of your data. Second, create a view and trim it down to the records, the fields and the geographic area one audience should see. Third, give each view its own sharing and editing settings, so the public gets a read only map while your crews keep editing the full layer. We'll work through a water main break example the whole way, because the same pattern fits service requests, outages and storm damage reports.

A view is a window, not a copy. A hosted feature layer view is a separate item in your content that points at an existing hosted feature layer. Think of a building with one room and several windows. Everyone looks at the same room, but each window has its own blinds, so each person sees only part of it. The data lives once, in the source layer. When a crew marks a break as repaired, every view shows the change immediately, because there's nothing to copy or sync. Each view is still its own item, with its own name, its own description and, as we'll see, its own sharing settings.

Creating a view. Creating a view takes a minute. Open the item page of your hosted feature layer, the one your crews edit, and choose Create View Layer. Give it a name that says who it's for, such as Water Breaks Public View, so nobody later wonders which item to share. ArcGIS Online creates the new item and marks it as a view. Then you open that view's item page and define what it shows, usually from the Visualization tab. One condition to remember: views come from hosted feature layers you own or administer, not from map image layers or external services.

Three ways to trim a view. A view definition trims the source in three ways. Rows: you write an attribute filter, for example only breaks whose status is Open, so closed work orders disappear. Fields: you tick off columns the audience shouldn't see, such as crew, caller name or internal notes. Area: you limit features to a region, like the North district boundary, so a district supervisor sees only their patch. You can combine all three. If you've ever written a query in a spreadsheet filter or a database, you already know how this works, and the next slide shows it as plain SQL.

Worked example: the public view. Here's our source layer with six recorded breaks, each with an id, a street, a status and the crew assigned. The public view definition, written as a query, says: keep only open breaks, and show just the id, the street and the status. First the filter runs, and the closed repairs drop out, leaving four rows. Then the field list applies, and the crew column disappears. The result is what residents actually see: four open breaks, no internal assignments. The source layer still has all six rows and every field for the operations team.

Test your view logic on paper first. Before you click through the settings, write each audience's rule down and check it against a small sample. No code is needed; a notepad or a spreadsheet will do. For each view, note three things: the filter, the fields it keeps, and how many rows you expect. Using our six sample breaks, the public view keeps open breaks and shows the id, the street and the status, so you expect four rows and no crew column. A view for crew A keeps only that crew's breaks, so you expect two rows. After you build each view, open its data tab and compare. If a count surprises you here, it would have surprised you on a public map too, and fixing a line on paper is much cheaper.

Sharing and editing per view. Here's where views really pay off. Every view is its own item, so sharing and editing are set per view. Share the source layer only with the operations group that manages it, and never with the public. Share the public view with everyone, with editing turned off. Share the crew view with a field crew group and allow editing, perhaps only updates, so crews can change a status but can't delete records. The same data now safely powers a public outage style map, a field app and an internal dashboard, and you never exported a single file.

Plan one view per audience. A simple habit is to list your audiences before you build anything. The operations center works from the full source layer. Field crews get a view per district, with editing. The public gets open breaks, a handful of friendly fields and no editing. Executives get every district but no personal information, because a strategic dashboard needs counts and trends, not caller phone numbers. Name each view after its audience and write the filter in the item description. Who else in your organization might need their own window onto the same data?

Common mistake: hiding is not protecting. The most common mistake is sharing the source layer publicly and then hiding sensitive fields in the pop-up, or filtering records in the web map, and assuming that's secure. It isn't. Pop-up settings and map filters only change what that one map displays. Anyone who can open the layer can still query it directly through its web address and download every field and every record, including caller addresses. A view definition actually limits what the service returns. So the rule is simple: if an audience shouldn't have a field or a record, give them a view that doesn't contain it.

Exercise: two views of one layer. Before the next lesson, try this. Take a hosted feature layer you own, such as water main breaks or service requests. If you don't have one, publish a small table of six or so sample records with a district, a status and a crew field. Create a public view that shows only open records and three fields, with editing off. Then create a crew view for one district with editing on. Open the data tab of each view and check that the rows and fields match your plan. In the project lesson, you'll use these views to build a dashboard ready web map.

Recap. Let's recap. A hosted feature layer view is a separate item that reads from one source layer, so edits show up everywhere at once and nothing is copied. In the view definition you trim rows with a filter, fields by hiding columns, and area by a boundary. And because every view has its own sharing and editing settings, you share the full source only with operations and give each audience exactly its own slice. With that, your dashboards can serve the public, crews and executives from a single source of truth.