Select to view content in your preferred language

QuickCapture loading everything BUT the Attachment when Offline

105
1
Thursday
GISMapLady
Occasional Contributor

We’re currently running into an issue where attachments are the only pieces not coming through to AGOL when capturing offline. I’m wondering if this might be related to spotty service when the Assessors are working in remote areas—for example, the upload may start but then get interrupted. Since the rest of the data is successfully sent, we’re not seeing an error message.

Is there a way to configure Quick Capture so it waits to send everything until the user is fully back in the office, rather than sending as soon as any internet connection is restored?

Is there a way for me to recover these images? Could they be stored in a cache somewhere?

 @JohnathanHasthorpe 

0 Kudos
1 Reply
JohnathanHasthorpe
Esri Regular Contributor

Hi — @GISMapLad

The behaviour you’re seeing may be due to a known configuration issue that can affect offline workflows with attachments.

 

Why this can happen

 

In QuickCapture, features and attachments are submitted as separate requests. In situations where connectivity is intermittent, it’s possible for a feature to be successfully sent, but the associated attachment upload fails.

This behaviour is dictated by whether the feature service supports applyEdits using GlobalIDs. You can check this by inspecting the service’s REST JSON for the following property: supportsApplyEditsWithGlobalIds

 
If this property is set to false, attachments are uploaded after the feature has been created and are not guaranteed to be successfully added. In low‑bandwidth or unreliable network conditions, this can result in the feature being created even though one or more attachments subsequently fail to upload.
 

However, when supportsApplyEditsWithGlobalIds is set to true, the behaviour is much more robust:

  • The feature is only sent once all attachments have been successfully uploaded
  • If any attachment fails, the feature is not sent, allowing the app to retry the entire submission later

In other words, enabling this property ensures that features will not be missing attachments. To find out how to do so, see the following blog: How to enable supportsApplyEditsWithGlobalIDs on your feature layer 

For hosted feature layers in ArcGIS Online, enabling Sync is often enough to resolve this. For non‑hosted or Enterprise layers, the same requirements apply as outlined in the Survey123 guidance referenced in the blog.

 

Controlling when records are sent

 

This can be achieved using the app’s Autosend setting. If Autosend is enabled, QuickCapture will attempt to upload records at a defined interval whenever the app is online.

To avoid this:

  • Disable Autosend in the app settings
  • Records will remain on the device until the user explicitly sends them (from the map page), for example once they are back on a stable Wi‑Fi connection

JohnathanHasthorpe_1-1777982234935.png

 

You should also note that Auto Send can be set using an organisational setting, meaning it is possible to enforce the setting for all users in your organisation.

 

Can the images be recovered?

 

Unfortunately, once a feature has been marked as successfully sent and the local record has been deleted, the attachments can’t be recovered. 

 

Summary

 

Based on your description, this issue is very likely related to a combination of:

  • Intermittent connectivity during upload
  • Automatic sending when a weak connection becomes available
  • A feature service where supportsApplyEditsWithGlobalIDs is set to false

Ensuring that this property is enabled is the most important step for preventing attachment loss in offline QuickCapture workflows.

0 Kudos