The Web Map That Wouldn't Load

Parcels never draws - most likely causes, in order:

1. Feature count vs. renderer. 2.1 million features exceeds what a default feature layer can render interactively; ArcGIS Online feature layers have practical display limits, and without scale-dependent visibility, generalization, or a tiled/vector tile representation, the client attempts to draw all features at once and stalls. The roads layer (40k) is under the limit and draws.
2. Sharing scope. The analyst shared the map, not the layers, to the group. A shared map grants access to the map item, but the underlying layers must also be shared to the same group for partners to draw them. If the parcels layer was left private (or shared to a different group), partners get a map whose parcels layer is inaccessible - hence the endless spinner on that layer while roads (perhaps shared separately or public) draws.
3. Data source. The parcels layer is a feature class in an enterprise geodatabase; if it was published as a referenced layer rather than a hosted layer, partners outside the network cannot reach the source. Hosting the data avoids this.

The decision error: publishing with defaults and sharing only the map, without checking layer sharing, hosting, and display limits for a 2.1M-feature layer.

Why it is read-only: Editability is controlled at the layer level, not the map level. The hosted table was likely published without editing enabled, or the group's sharing settings grant view-only access, or the partners' accounts lack edit privileges on the item. Sharing the map does not confer edit rights on the table.

To enable editing:

1. Open the hosted table's item details and enable editing (and, if needed, sync for offline).
2. Ensure the table is shared to the group with edit permissions - group sharing has view/edit distinctions, and the item's sharing must match.
3. Confirm the partners' roles allow editing (a Viewer role cannot edit regardless of item settings).

Risks to weigh:

• Concurrent edits and conflicts - 25 external partners editing 500 records can create version conflicts; decide whether to use versioned editing or branch versioning and how conflicts are resolved.
• Data integrity - external editors may enter invalid values; apply domains, subtypes, and attribute rules before enabling editing.
• Audit and accountability - enable editor tracking so changes are attributable.
• Security - editing by external partners is a higher trust level than viewing; confirm the partner agreement covers it.

The judgment: enabling editing is not a checkbox; it is a governance decision about who may change authoritative data and how conflicts are handled.

Diagnosis: A blank basemap for a partner in another country points to one of:

• Basemap access/region restrictions - some basemaps are served from regional endpoints or are restricted by organization settings; a partner outside the region may not reach the tile service.
• Network/firewall - the partner's network blocks the tile service domain.
• Basemap not shared - if the basemap is a custom or organization basemap, it may not be shared to the group, so only that partner (without org access) sees blank.
• Projection/extent - less likely, but a basemap with a limited extent would be blank outside it.

Fix that serves all partners:

1. Use a globally available, publicly accessible basemap (e.g., a standard world imagery or world street basemap) rather than a regional or organization-restricted one.
2. Share the basemap item to the same group, or confirm it is public.
3. Test from an external network (not the agency LAN) before declaring the map published - the analyst's own network may mask the problem.
4. Provide a fallback: if the basemap fails, the map should still show the operational layers (parcels, roads) so partners are not left with a blank canvas.

The principle: a shared map must be tested from the audience's network and geography, not the publisher's.