AdminConsole
Tutorials/Advanced
Advanced90 minREST + Android

Build proof review and rework for field jobs

Capture purpose-bound evidence, route weak submissions to review, request rework, and preserve decision history.

By the endAn auditable proof workflow that cannot silently overwrite rejected evidence.
Real-world scenario

Build against an explicit contract

A field-work organization must distinguish captured evidence, automated policy, human review, rework, approval, and final closure.

A Mappls developer projectA restricted REST applicationFixture data with no production credentialsA request, aggregate, or correlation ID strategy
Step 1

Define the user and system contract

A field-work organization must distinguish captured evidence, automated policy, human review, rework, approval, and final closure. Record the region, data freshness, latency budget, privacy purpose, credential owner, and fallback before choosing an SDK or endpoint.

Step 2

Define evidence policy

Version required fields, media types, location accuracy/freshness, consent/purpose, checklist, signature, retention, and automatic-review thresholds.

Workmate · SDK or product slice
{
  "externalId": "JOB-2026-004219",
  "type": "equipment_inspection",
  "assigneeId": "worker_1288",
  "location": { "mapplsPin": "MMI000" },
  "window": { "startsAt": "2026-08-17T04:30:00Z", "endsAt": "2026-08-17T06:30:00Z" },
  "requiredProof": ["arrival_location", "checklist", "photo", "customer_signature"]
}
Step 3

Append submissions

Give each proof submission an immutable ID/content hash, event/receipt time, actor/device, task version, provider identity, and redaction state; never overwrite a rejected attempt.

Step 4

Make review a state machine

Route weak evidence to a named reviewer, record approve/reject/rework reasons, issue a new attempt identity, and allow task closure only from an approved policy-compatible submission.

Step 5

Prove the production behavior

Automate the happy path and every named failure. The release is ready only when rejected evidence remains auditable; automated policy cannot override human rejection; closure names the exact approved submission. Capture provider request identity without logging credentials or unnecessary precise location.

Recovery design

Failure modes you must exercise

offline duplicate submission

Fail fast with a typed, user-safe outcome and preserve the original request identity.

media upload succeeds but command times out

Keep the last verified state, mark freshness honestly, and retry only within the documented idempotency boundary.

review policy changes during rework

Reconcile durable local and provider evidence before declaring success or issuing a compensating command.

Never turn uncertainty into success

Timeout after a stateful command is an unknown outcome. Query by provider/idempotency identity or wait for authoritative events; do not blindly retry a new command.

Acceptance criteria

Definition of done

rejected evidence remains auditableautomated policy cannot override human rejectionclosure names the exact approved submission

REST production checks

Credentials never reach a browser or mobile bundleTimeout, retry, and idempotency policies are explicitCoordinates, addresses, and identifiers have data-retention rulesEvery operation is attributable in logs and usage reporting
Grounded implementation

Continue from source, contracts, and a full app

These links resolve to repository-derived evidence; unsupported package names and endpoints are not filled in from guesswork.

Study the complete Field-service task lifecycle state machine
Tutorial complete

Run it, break it, then observe it

Start with fixture credentials, execute the failure plan, and use request logs, usage, webhook evidence, and operational metrics before promoting traffic.