Offline capabilities

What it is

Syndik8 is offline-first. The app keeps a local copy of your syndicate’s data on your device and uses it for almost everything the UI shows. Reads and writes work without an internet connection; writes queue and sync on reconnection.

The data flow is: your device ↔ Syndik8’s sync service ↔ Syndik8’s server. The app replicates a filtered slice of the server data to the local copy on your device and pushes local writes back.

Who can use it

Every member, on every supported platform. Offline behaviour is not opt-in and there is no per-user toggle.

Where to find it

The behaviour is part of every screen. You do not navigate to an “offline mode”.
The traffic-light profile avatar in the navigation chrome is the live indicator:

Colour	State
Green	Connected and receiving real-time updates.
Amber	Reconnecting.
Red	Offline: no sync session and no network.

Fields / options

What syncs to the device

The app holds a local copy of almost everything you look at on a normal day. Broadly:

Area	What’s cached locally	Writes
Core	Your syndicates, memberships, and member profiles	Offline
Assets	Assets, asset types, and per-asset billing configuration	Mixed: billing configuration writes go online
Calendar	Bookings and events	Offline
Usage and maintenance	Usage logs, maintenance items, maintenance templates, maintenance logs, and squawks	Offline
Finance	Transactions, expenses, and the configured billing schemes	Mixed. Members can see balances, expenses, and rates without a connection. Submitting an expense works offline (queued); ledger writes (approvals, settlements) are online-only.
Payments (read-only)	Direct-debit mandate state, member funds (loans / goodwill / refund-as-credit), and “debit incoming” advance-notice cards	Online-only writes. Setup and changes go through online forms.
Notifications	Your notification feed, including read/unread state and deletions	Offline
Documents	Asset and syndicate documents (ship’s papers), with an opt-in cache on multi-asset syndicates	Online for uploads; offline read on cached files. See Offline document cache.

Sync follows active membership. Each device only receives data for syndicates where the user’s membership is active. The moment a member leaves or an admin removes them, the syndicate’s data stops syncing to their device and the offline cache no longer refreshes; past entries already on the device remain until the next clean sync clears them.

What’s deliberately online-only

Some areas of the app are kept off the offline cache by design:

Ledger sources of truth: settlements, reversals, disbursements, payment events. Money conflicts are unacceptable.
Invites depend on server-side checks that have no offline contract.
Notification preferences: a per-user setting fetched on demand.

What works offline

Capability	Behaviour
View cached data	Calendar, bookings, usage, maintenance, squawks, members, balances, all read locally.
Maintenance check before booking	Computed locally from cached maintenance items, asset meter, and recent usage logs. ~10 ms typical; no network round-trip.
Create a booking	Saved locally; syncs as pending or confirmed on reconnection. The success snackbar shows Booking created, with Will sync when you’re back online on a second line.
Approve, reject, confirm, or cancel a booking	Saved locally; syncs on reconnection. Snackbars carry the same “will sync” suffix offline.
Log usage	Stored locally; syncs on reconnection. Attaching a meter photo needs a connection.
Report a squawk	Stored locally; syncs on reconnection.
Read transactions and statements	Financial reads are offline-capable from the cached ledger view.
Submit an expense	Saved locally; syncs on reconnection. Attaching a receipt needs a connection, so submit without one when offline.
Mark a notification read, or delete one	Saved locally; syncs on reconnection.
View votes and cash calls	Read locally. Casting a vote or raising a cash call needs a connection (see below).
Open a cached document	Cached ship’s papers render instantly from the device. See Offline document cache.

What requires a connection

These actions are gated by a button that disables when the device is offline. Tapping (or hovering on web) shows the reason snackbar listed below.

Action	Reason snackbar	Why blocked
Create or revoke an invite	Invites need a connection. Try again when you’re online.	Depends on a server-side check.
Finalise a booking (single or bulk)	Settlements need a connection. Try again when you’re online.	Writes to the ledger. Money conflicts are unacceptable, so the action cannot be queued.
Approve or reject an expense	Approval needs a connection. Try again when you’re online.	Writes to the ledger.
Cast a vote, or raise or cancel a cash call	Voting needs a connection. Try again when you’re online.	Voting integrity (who may vote, and the closing deadline) is enforced on the server.
Start payment provider setup	Payment setup needs a connection. Try again when you’re online.	Calls an external service that has no offline contract.
Update notification preferences	n/a; the page fetches online	The preferences are fetched and saved on demand.
Payment checkout	n/a	Web-only, opens the checkout URL in a new tab (see upgrade prompt).
Load a legal document not yet cached	n/a	Terms of Service and Privacy Policy are fetched from the server; a not-yet-cached copy is unavailable offline.

Behaviour rules

Writes queue locally. A booking, usage log, or squawk created offline is written to the device immediately and appears in the UI. The app pushes the change when the device reconnects.
Last-write-wins for most conflicts. If two devices edit the same record offline and reconnect, the later write replaces the earlier one. There is no three-way merge.
Overlapping bookings are rejected on the server. Two members who create overlapping confirmed bookings offline will both see them locally; when sync runs, the one that reaches the server first is accepted and the other is rejected by a server-side conflict check and surfaces as a sync error.
Tentative bookings do not conflict. Multiple tentative bookings can coexist on the same slot; the conflict check covers confirmed only.
Photos need a connection. Attaching a photo (a meter photo on a flight log, or a receipt on an expense) uploads it to storage, which has no offline queue. With no signal, save the flight log or expense without the photo.
The traffic-light indicator reacts in seconds. The operating system tells the app when the network goes away, so the colour flips to red within seconds rather than waiting for a heartbeat timeout.
First sync on a new sign-in. When a different person signs in on a device, the app clears the previous user’s local data and re-hydrates from scratch; signing the same person back in keeps the local copy for a fast start. Network outages during a from-scratch first pass mean the UI is usable only for the areas that completed before the outage.
Online-only buttons disable themselves and explain why. Booking finalisation, expense approve/reject, invite generation, payment-provider setup, and casting a vote or raising a cash call all watch the connectivity stream. When the device is offline, the button is disabled; tapping it shows a short reason snackbar (e.g. Settlements need a connection). The button re-enables automatically when connectivity returns.
Sync-backed write success messages adapt to connectivity. When you create or edit something while offline, the success snackbar appends Will sync when you’re back online on a second line so it’s clear the change is queued, not delivered.
Maintenance check before booking is computed locally. When you open the booking dialog, Syndik8 evaluates the asset’s open maintenance items (hours-based and calendar-based) against the cached meter reading and recent usage logs in around 10 ms, with no network call. The amber/red warning surfaces in the dialog whether the device is online or offline.
Local data persists on the device. On mobile it survives app launches; on the web it stays in the browser’s storage and survives closing the tab (the web build simply cannot sync in the background while the tab is closed). The local copy is cleared only when you choose Clear data while signing out, or when a different person signs in on that device. Cached document files (mobile) deliberately survive a normal sign-out (see the offline document cache).

For the reasoning behind offline-first, see Offline-first architecture.