Mobile Offline Work and Operations

How queued responses, file uploads, field tasks, and review steps behave when a subscription expires mid-collection — and how they recover.

Offline responses across an expiry

This is the scenario field teams hit most often: a survey is downloaded while the subscription is healthy, responses are collected in the field, and by the time the device reconnects the organization's subscription has lapsed.

The guarantee: no collected work is lost.

The verified sequence:

1. The device downloads the survey while the subscription is active.
2. Responses are captured offline. Each queued item carries its SurveyVersionId, its content hash where applicable, its answers, and a clientSubmissionId.
3. The subscription expires.
4. The device reconnects and tries to sync.
5. The server refuses with errorCode 1001 / SubscriptionExpired.
6. The server creates no response, no answers, no field task completion — and it does not consume the idempotency key.
7. The organization renews.
8. The device retries the identical payload.
9. The server accepts it and saves it exactly once.
10. Any further retry of the same payload returns the canonical "already accepted" result with the same response identifier. No duplicate is created.

The idempotency key

The key for a response submission is clientSubmissionId.

It is not clientUploadId. That is the separate retry key for file uploads, a different operation with its own rules. Confusing the two produces either duplicated responses or lost uploads.

Client rules on 1001

Do:

• keep the queued item
• keep the same clientSubmissionId
• keep the original SurveyVersionId, content hash, and answers exactly as captured
• back off and stop automatic retries
• show a "renewal required" state
• retry the identical payload once service is restored

Do not:

• delete or discard the queued item
• mark it as successfully synced
• generate a new clientSubmissionId
• rebuild or re-serialize the payload
• sign the user out

A SubscriptionExpired result is retryable and non-destructive. It is not a validation failure, and it must never be treated like one.

File uploads

A refused upload leaves nothing behind in either direction: no database record without a file, and no file without a record.

File problems and subscription problems stay separate. An unsupported file type, a corrupt file whose contents do not match its declared type, a question that does not accept files, or a survey belonging to another organization are all refused on their own merits, with their own error codes — never as SubscriptionExpired. Equally, a genuine expiry is never reported as a file problem. A client must not present a rejected upload as successful.

Field tasks

The key guarantee: expiry can never leave a field task partly or wrongly completed. A refused attempt does not set the completion flag, does not stamp a completion time, and does not record an actor. The task simply stays open until service resumes.

Assignment and organization boundaries are unaffected by subscription state. A collector who is not assigned a task is refused whether the subscription is active or not, and learns nothing about the task either way.

Review workflow

The review chain is:

Submit for review → Start review → Return for correction → Resubmit → Start review → Approve

Reviewer steps are gated just as collector steps are. This is deliberate: approval is the only way a review-workflow response reaches its completed state, so leaving reviewer actions open would let an expired organization finish collecting work through the review path — the precise outcome expiry exists to prevent.

Reading a response's current lifecycle state is not gated. You can always see where a response stands; you just cannot move it.

A refused transition leaves no partial step: no status change, no revision increase, no audit entry, and no field task completion.

Related pages

• Mobile Subscription Contract
• Data Safety and Recovery
• What Happens When Your Subscription Expires