Offline Field Crews and a Layer That Will Not Sync
Metro Portland's Bureau of Maintenance publishes a hosted feature layer of 412,000 streetlight assets to an ArcGIS Enterprise portal federated with a two-machine server site. Two hundred field staff use Field Maps with offline areas sized to their maintenance districts; the largest district holds 96,000 points and 41,000 photo attachments averaging 1.8 MB. Last week the offline download for the North district failed with 'The requested operation is not supported by this service,' and crews that did sync lost 30 inspections they had recorded offline. The layer is published with all 38 attributes editable, and an analyst enabled keep-track-of-created-and-updated-features after the fact by republishing. Warehouse staff report that a simple filter in Map Viewer takes 20 seconds. Offline crews depend on this layer daily.
1. Diagnose the offline download failure, explain how the 30 inspections were lost, and state what must be verified before any further republish.
Read the worked answer
'Not supported by this service' is a configuration verdict. Offline use in Field Maps requires, on every layer and table in the web map: sync enabled, a GlobalID field, editor tracking fields, and attachments enabled where photos are in scope. Typical violations here: the inspection table that appears in the popup was added as a non-editable view or lacks sync; the streetlight layer is registered or referenced rather than hosted; or sync was enabled on one layer during the republish and not on its dependents. Verify from each item's REST endpoint that capabilities include Sync and extract, then test a small offline area before announcing availability.
How the edits were lost. Republishing replaces the service. Any downloaded offline area holds a schema and service generation that no longer matches, so sync is refused and the local edits sit stranded until the area is discarded. Before touching the service again, have crews export pending edits from Field Maps, or recover the runtime geodatabase from the device, then re-download.
Standing rule. Never republish a service that has live offline areas. Make schema changes as a planned release with a coordinated re-download window, and reduce the attachment burden first: 96,000 points with 41,000 photos averaging 1.8 MB will not download reliably regardless of the configuration.
2. Explain how the 38 editable attributes and the after-the-fact editor tracking contribute to slow filtering and to sync risk, and what you would change.
Read the worked answer
Editable fields drive payload size. Every edit transmits all editable attributes, and each one is a chance for an offline editor to overwrite a warehouse update made while they were disconnected. Trimming the editable set is both a performance and a data-integrity measure: leave fields visible but read-only if crews never write them, and let editor tracking supply created-by, created-date and last-edit fields instead of editable copies.
Editor tracking enabled after the fact. Enabling it retrospectively means all existing rows carry null creation metadata, and any republish to apply it invalidates offline areas. If the field must be backfilled, do it as a controlled release with a documented, single source for the historical values, not as an assumption.
The 20-second filter. That is either a missing index or a client-side query over 412,000 rows. Add attribute indexes on the fields used in the filter and popup, confirm the request is server-side and paged, and only then consider raising the maximum record count, which does nothing for an unindexed filter. If the filter is a standing business rule, publish a view with the definition baked in rather than teaching users to type it.
Attachments. Keep them in their own table and confirm the popup is not dragging them into every query.
3. The warehouse wants to replace the layer contents from its asset management system every night. Explain how to keep that feed while preserving offline editing.
Read the worked answer
Offline editing forces hosted. Field Maps sync requires a hosted feature layer; a referenced layer cannot be taken offline. That constrains the feed design, not the other way around.
Never truncate and append. Truncate plus append replaces every row, issues new GlobalIDs, destroys editor tracking and sync lineage, and invalidates every downloaded offline area. It will look like it works in the office and will strand two hundred crews in the field.
Update incrementally. Read the warehouse extract, match on a stable asset key, and apply only changed rows via an update cursor or a batched apply-edits call with rollback on failure. Delete only rows the warehouse explicitly retires, and decide in advance how a warehouse deletion interacts with an inspection recorded offline against that asset: usually the asset is retired, not deleted.
Publish views for consumers. Keep one editable hosted layer for crews and a read-only view with only the needed fields and a fixed definition query for the warehouse and public maps. Field-level visibility keeps internal notes out of shared items, and schema churn stops rippling outward. Schedule the feed outside the sync window, and alert crews before any change that requires a re-download.