A barcode scan, a signature image and a green message can each look like proof of delivery. None of them is sufficient by itself. A dependable workflow must show which shipment was handled, which delivery rule applied, what evidence was captured, whether an exception changed the result and whether the authoritative system accepted the submission.
This guide uses an editorial delivery scenario to show what a buyer and integrator should validate on a rugged handheld. It does not assume that an AIDC GO model includes a proof-of-delivery application, signature feature or camera workflow.
Start with the delivery record, not the signature box
Define the business record that the worker is completing: shipment, stop, consignment, order or asset transfer. The scanned value should resolve to that record before the application asks for a signature or photo. A decoded label only proves that the device obtained a value; the application must still decide whether that value belongs to the current route, stop and recipient context.
Use the handheld-terminal category to compare current device fields, then give the integrator the actual label samples, route data and application screens. The phone-screen barcode guide is relevant when a recipient presents a digital code, but optical capture still does not authorize delivery.
Define what each piece of evidence represents
A signature is usually an attachment or field within a larger record. Esri's Survey123 media-question documentation describes a named signature appearance that saves the signature as a JPG attachment, and it explains how attachment keywords associate media with specific questions. That is a useful named software example; it is not evidence that another application creates the same relationship.
State whether the project needs a recipient name, role, signature, photograph, exception code, item count or geolocation. Then define which are mandatory for a normal delivery and which become mandatory only for damage, shortage, refusal or unattended delivery. A picture of cartons does not prove which order they belong to unless the application preserves the relationship.
Keep capture, local completion and server acceptance separate
The device can finish a form while the submission remains local. Survey123's mobile quick reference describes an Outbox for completed surveys that have not yet been submitted, including when the device was offline. The same distinction should be explicit in any delivery application: completed on device, queued, sent, accepted, rejected or requiring review.
The offline transaction guide explains retry identity and unknown receipts in more detail. For proof of delivery, the buyer should also verify that the shipment, evidence attachments and exception state remain one logical submission through every retry.
Compare what the visible signals actually establish
| Visible signal | What it can establish | What still needs independent confirmation |
|---|---|---|
| Shipment barcode is decoded | The tested capture path returned a value from that label | The value belongs to the intended stop, shipment and current delivery task |
| Signature or photo appears in the form | The application holds an attachment or drawing in the observed record | The attachment is linked to the correct shipment and survives submission, export and later review |
| Device shows a completed state | The local workflow reached its configured end state | The authoritative system accepted the record and all required attachments |
| Record appears in the backend | A server-side record is visible after synchronization | The final status, recipient context, exceptions and evidence match the device submission without duplication |
Record the task ID, scanned identifier, attachment count, local state, submission identity and server result. This makes a missing attachment or duplicate retry visible instead of treating one success banner as the entire audit trail.
Walk one delivery through normal and exception branches
Consider an editorial example with two deliveries at the same building. The worker opens stop A, scans the shipment label and sees the expected recipient and item count. The recipient signs, the worker submits, and the backend records an accepted delivery. The tester then opens stop B but scans a carton assigned to stop A. The application should reject or clearly redirect that mismatch before any new signature is attached.
For an exception branch, the worker records visible package damage, adds the required photo and selects the approved exception code. If connectivity disappears after local completion, the application keeps the record in a distinguishable pending state. After reconnection, the tester confirms one accepted server record with the correct attachments and no duplicate delivery event. This is a suggested acceptance sequence, not a customer case or measured product result.
Preserve identity when evidence is edited or reviewed
If a user can reopen a record, define whether a new attachment supplements or replaces the original, who can make the change and how the backend exposes that history. Survey123's tracking guidance distinguishes captured start/end metadata from editor-tracking fields; it illustrates why capture context and later edits should not be collapsed into one timestamp or user name.
The field-inspection article covers attaching photos to an asset inspection. Delivery evidence has a different business object and acceptance rule: shipment completion, recipient context and exception disposition must remain aligned.
Send a complete workflow for configuration review
Provide the application name and version, target operating system, shipment identifier samples, route and stop rules, signature/photo requirements, exception codes, offline behavior, attachment limits, retry identity, backend acceptance response and export or audit needs. Include the actual labels, screen sequence and destination country.
Also state who can reopen, correct or cancel a delivery and what the next worker sees after that change. A technically successful upload is not a complete handover if the route screen continues to show the old state or if a replacement device cannot distinguish accepted work from pending work.
Use the project brief template to keep those inputs together. Send the workflow and model shortlist to Integration Support or Contact so the current hardware fields and available documentation can be checked. The application owner remains responsible for delivery authorization, record identity, evidence retention and final business acceptance.