Skip to content
FRA Flow
Menu
SoftwareBS 9792AppPricingAssessorsToolsDocs
Try FRA Flow freeTalk to usLog in

Working offline

How FRA Flow keeps the capture flow running when the iPad has no signal, and what happens to your data when you reconnect.

By Richard Pryce·Last updated

Site visits routinely lose signal. Lifts, basements, plant rooms, gable ends behind thick walls. FRA Flow is built to keep the capture flow running for a full visit (and longer) without a network, and to drain everything cleanly when you reconnect.

What works offline

Once you have pre-flighted the assessment, the iPad has every piece of data the on-site flow needs:

  • The property record (address, building type, contact for keys, known limitations).
  • The BS 9792 section template seeded for the assessment.
  • The previous FRA, if one is on file.

While offline, every action you take lands locally and queues for sync:

  • Create or rename a location.
  • Capture an observation. Photo, voice, type. All three modes work without a network.
  • Mark a section as Satisfactory, Action required, or Not applicable.
  • Edit or delete an observation.
  • Repeat an observation across multiple locations.

The workbench renders the same way it does online. The only visible difference is a small "Local" pill on observation cards that have not yet synced.

What does NOT work offline

The full set, so there are no surprises:

  • Generating the AI draft. Generation runs server-side and needs a network. The Generate-draft button still works once you reconnect.
  • Reviewing the report. The report viewer reads from the server, not from the cache.
  • Editing landlord, dutyholder, or property records. Pre-pilot these are server-only writes; the on-site flow does not need them.
  • Sign-off (M3 feature anyway).

How the queue works

Each mutation you make offline lands on a per-device queue:

  • Create observation → enqueue an "observation_create" mutation.
  • Upload a photo → enqueue a "photo_upload" mutation.
  • Mark a section → enqueue a "section_conclusion" mutation.

When the network returns, FRA Flow drains the queue in the order you made the mutations. A photo upload that depends on its observation always waits for the observation create to complete. A section conclusion that depends on a section that already existed at preflight does not wait for anything.

If a single mutation fails (rare, usually a 5xx from a sub-processor), it retries with exponential backoff. The rest of the queue keeps draining. A stuck queue surfaces in the sync indicator at the top of the workbench; the sync-stuck troubleshooter covers the recovery path.

How long can you stay offline

Two practical limits:

  • iPad storage eviction. iOS may evict offline storage for sites you have not opened in seven days. If your iPad has not opened FRA Flow for a week, the cache may be gone and you need to re-preflight. In practice this matters only for very long gaps between visits.
  • Cache freshness. FRA Flow re-runs preflight against the server when the cached row is older than 24 hours. So if you cache today and visit tomorrow, you get fresh data on first launch (assuming connectivity), without having to re-preflight manually.

Neither limit caps the actual length of a single visit. A full day on site without signal is fine; the queue holds and drains when you are back to wifi.

Battery-impact note

Photos compress locally before upload, and the AI side runs server-side, so the iPad's CPU is mostly idle while you walk the building. Battery life mirrors normal Safari + camera use. Voice recording does pull more CPU briefly, but only during the recording itself.

Where to go next

  • Photo capture for what happens to a photo while the queue drains.
  • Voice notes for the transcription path that runs after reconnect.
  • Sync is stuck for recovery if the queue does not drain.