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 live indicator is the Profile tab’s person icon in the navigation bar or rail. It is the glyph itself that changes colour, not your profile photo; the icon never shows your photo. The same icon also carries your unread-notification badge, which is unrelated to connection state.

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

The colour is not the only channel. The icon carries the state in words as well — Connected, Reconnecting or Offline — so a screen reader announces it and a hover shows it, and the unread badge is announced as a count of notifications rather than a bare number.

Green is also what you see for the moment before the app has worked out its connection state, so treat green as “no problem reported” rather than as a positive confirmation that sync has started.

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, “debit incoming” cards naming what a live collection is taking, refunds — both the ones still settling at the payment provider and the ones waiting in the admin queue to be explained, including whether the provider later reported one failed — and the bank disputes behind them, so a charge your bank is still looking into carries an Awaiting your bank pill on its own row instead of a Pay button	Online-only writes. Setup and changes go through online forms. Issuing a refund, recording what one meant, and clearing one from the queue are all online buttons.
Subscription (read-only)	Your syndicate’s plan, what it includes, and what it is currently billed for	Online-only writes. Cached so the app can tell you an aircraft or member costs nothing before you add it, even with no signal. Changing the subscription itself is always online.
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: payment events. Money conflicts are unacceptable, and sending money back to a member calls the payment provider, which cannot be queued. Settlements, refunds and reversals are a partial exception and only in one direction — you can read them offline (see the payments row above), because their state is a record of what the provider has already done or is doing. That is how the app can tell you a collection is on its way without a signal, and how a charge your bank is still looking into can say so on its own row rather than offering you a payment nothing would accept. Every payment and every refund decision is still an online button, because it rests on questions only the server can answer, such as whether these charges have already been paid back.
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. A meter photo is held on the device and uploaded when you are back online (mobile only).
Report a squawk	Stored locally; syncs on reconnection. A photo is held on the device and uploaded when you are back online (mobile only).
Read your transactions and balance	Your ledger and the balance above it are read from the local cache. Exporting that ledger as a statement is the exception, because a statement also shows your payments — see below.
Submit an expense	Saved locally; syncs on reconnection. A receipt photo is held on the device and uploaded when you are back online (mobile only).
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.
Open a vote	Opening a vote needs a connection. Try again when you’re online	Voting integrity (who may vote, and the closing deadline) is enforced on the server.
Cast a vote	Casting a vote needs a connection. Try again when you’re online	As above.
Raise a cash call	Cash calls need a connection. Try again when you’re online	A cash call posts charges to every member’s ledger.
Start payment provider setup	Payment setup needs a connection. Try again when you’re online.	Calls an external service that has no offline contract.
Download or share a statement	Statements need a connection. Try again when you’re online.	A statement shows your payments as well as your charges, and payments are a ledger source of truth kept off the device. Without them the closing balance would be every charge you have ever had.
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 taken offline are held on the device and uploaded later (mobile only). Attach a meter photo to a flight log, a receipt to an expense, or a photo to a squawk report with no signal and the record saves straight away; the image is kept on the device and marked Will upload when online. Syndik8 uploads it and attaches it to the record on its own, when the app next has a connection — at start-up, and again each time the signal comes back. You do not have to return to the screen.
A photo waits for the person who took it. On a shared device, a photo taken by one member and still waiting to upload is left alone while somebody else is signed in, and goes up when its owner signs back in. Photos are never uploaded under another member’s name. Choosing Clear data while signing out deletes any still-waiting photos along with the rest of the local copy, so upload before you do that.
On the web, a photo still needs a connection. Browsers have no durable place for the image to wait, so attaching one offline fails there and the flight log, expense or squawk report should be saved without it.
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. The app checks that the clear worked before it opens the local copy, and if it cannot confirm that, it stops on the loading screen with an explanation rather than risk showing you the previous person’s data. On the web that usually means another tab or window still has Syndik8 open; close it and restart.
Handing the device straight on. If one person signs out and another signs in without closing the app, Syndik8 stops using the local copy the moment it sees a different person, and reads from the server until the clear has finished. The same holds when nobody signs out at all: opening an invitation or confirmation link on a device somebody else is signed into replaces the session outright, and that is treated as a change of person in exactly the same way. Signing in behind somebody else therefore takes a second or two longer and shows the loading screen while it waits, but you never see the previous person’s syndicate, diary or balance. The home-screen widget and the watch stay on the signed-out tile through the changeover rather than briefly showing the wrong syndicate. Signing yourself back in is unaffected and stays instant.
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.
An empty screen says which kind of empty it is. Almost everything you look at is read from the copy of your data held on the device, and that copy answers instantly whether there is genuinely nothing to show or nothing has arrived yet — the two are the same empty list. So on a freshly installed app, after signing in on a new device, and for a moment after signing out and back in, screens that would otherwise tell you something reassuring say Still syncing instead: that you owe nothing, that nothing is pending, that maintenance is up to date and that an aircraft is all OK are claims we will not make until the data behind them has actually reached you. They switch to the ordinary wording as soon as it does. On the web there is no local copy to wait for, so an empty list is answered by the server and reads as genuinely empty straight away.
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.