One layer, many audiences — hosted feature layer views in ArcGIS Online

Sooner or later every ArcGIS Online org hits the same wall: one authoritative dataset, three audiences. The public should see some of it. A field crew needs to edit part of it. A partner agency wants their slice and nothing else. The reflex — exporting copies — is how data governance dies. The right tool has been sitting in the item page the whole time: the hosted feature layer view.

A view looks and behaves like a feature layer, but it stores nothing. It is a server-side definition over an existing hosted feature layer that exposes only the features, fields, and capabilities you choose. Edit the source data and every view reflects the change immediately — because there is only ever one copy of the data. Per Esri’s documentation: “If the underlying data changes in the original feature layer, the changes are reflected in all associated views.”

What a view can restrict

Three independent levers, all enforced server-side by the feature service — not by the client application:

The sharing model is the quiet superpower. Views “support all of the sharing levels available regardless of the underlying feature layer’s sharing level” (Types of datasets). Your source layer stays private to the data team; the view built from it can be shared to Everyone. The public URL is the view’s URL — the source service is never exposed.

Build one in the portal — five minutes

Esri’s Create a feature layer view tutorial walks the full workflow against the Santa Monica Parcels sample. Condensed:

1. Open the source feature layer’s item page and click Create View Layer → View layer. (You must be the layer’s owner — views are created by owners, from existing hosted feature layers.)
2. Under Layer definitions, add a filter expression — e.g. usetype is Commercial — to limit which features the view serves.
3. Under Fields, select only the columns this audience should ever see; everything unchecked is hidden from the service, not just from a popup.
4. Name it, tag it, and Create. The view gets its own item page, its own service URL, and its own sharing level.
5. On the new view’s item page, set sharing and editing to match the audience — a public read-only view, or a group-shared edit view for the field crew.

Script it — ArcGIS API for Python

For anything you will do more than once — standing up the same public/edit/partner triplet for every project — script the view creation. The pattern comes straight from the official tutorial: create the view from the FeatureLayerCollection manager, then push a definition with the filter and the visible-field list.

# flc is a FeatureLayerCollection for the source hosted feature layer
view_item = flc.manager.create_view(name="Parcels - public view")

# expose only the fields this audience should see (plus the OID)
view_flds = view_item.layers[0].properties.fields
vis_flds = [
    {"name": f.name, "visible": True}
    if f.name in ["apn", "situsfulla", "usetype", "usedescrip"]
    or f.type == "esriFieldTypeOID"
    else {"name": f.name, "visible": False}
    for f in view_flds
]

# server-side filter + field visibility, applied in one definition update
layer_def = {
    "viewDefinitionQuery": "usetype = 'Commercial'",
    "fields": vis_flds,
}
view_item.layers[0].manager.update_definition(layer_def)

print(f"View created: {view_item.id} -> {view_item.url}")

The key call is FeatureLayerCollectionManager.create_view(); the viewDefinitionQuery and fields properties ride in through update_definition(). The same workflow is available in ArcGIS REST JS (createFeatureService with isView: true, then updateServiceDefinition) if your automation lives in TypeScript.

Three patterns we ship constantly

1. The public window

Source layer: private, editable, full schema. View: definition query down to publishable records, sensitive fields hidden, editing off, shared to Everyone. This is the layer your public web app consumes — and because the filter and field mask are enforced by the service, no amount of devtools curiosity on the client can reach what the view does not serve.

2. The field-crew editor

The docs’ own example: a parcels view “configured to only allow editing on commercial parcels”, shared to the group that needs it. The crew edits through the view; edits land in the one authoritative layer; the analyst’s dashboards update without a sync step.

3. The partner slice

A neighboring agency needs your hydrants inside their boundary — not your whole network. A view with a spatial or attribute filter gives them a live service scoped to exactly their area of interest. No exports, no quarterly “refresh” emails, no stale copies in someone else’s org.

The fine print

• Ownership: you must own the source hosted feature layer to create a view from it, and views live in the same org as their source.
• Views are layers: a view “supports all of the same functionality as a feature layer” — popups, renderers, joins into web maps, use in apps — so downstream consumers never need to know it is a view.
• Schema follows the source: a view exposes a subset of an existing layer; structural changes happen on the source, and views inherit them. Plan schema changes with your views in mind.
• Views are not a substitute for thinking: a hidden field is hidden from the view, but anyone with access to the source item still sees everything. Sharing hygiene on the source layer still matters.

References

• Types of datasets — Feature layer views (Esri Developer documentation)
• Tutorial: Create a feature layer view (Esri Developer documentation)
• Introduction to feature services (Esri Developer documentation)
• Glossary: feature layer view (Esri Developer documentation)
• ArcGIS API for Python reference: FeatureLayerCollectionManager.create_view