Parked and held

Two apps talking to each other will eventually fail to. When the other app is not answering, the message waits somewhere you can see it. When you switch a connection off, nothing is sent to that app at all.

Queued, then confirmed

Nothing is sent and forgotten. Every message to a connected app is written down first, sent second, and marked delivered only when the other app confirms it applied it.

That ordering is the whole reliability story. A message can never be lost because the app crashed after sending it — the record was made before the attempt, so a message that never got a confirmation is still sitting there waiting to be retried.

The states a message can be in

The health panel counts each connection’s outbound messages by state:

State	What it means
Queued	Written down, waiting its turn
Sending	An attempt is in flight right now
Delivered	The other app confirmed it applied it
Held	Parked — the other app is not answering, or Shopify is rate limiting us. Releases itself
Rate limited	The other app said “not now” — a pause, not a failure
Failed	The other app rejected it, or the attempt errored
Never delivered	Held so long it was given up on. Permanent

Rate limited deserves a note. When a connected app asks Floormode to slow down, that is a normal, healthy response to a busy moment — not an error. A pause does not count against a message’s retry attempts, so being throttled can never, by itself, cause a message to fail. The panel says as much: nothing is lost — a rate limit does not spend a delivery attempt.

Held while the other app is not answering

If the other app is down or cannot be reached, messages for it are held, in order, and the panel shows them as Held with the age of the oldest one. Floormode retries one message every so often and sends the whole backlog the moment one gets through, in the order it was produced. A Shopify rate limit is handled the same way. Neither needs you.

Switching a connection off

A switched-off app gets nothing: Floormode writes no message for it and keeps no backlog. Your own records stay here (the count, the receipt, the alert on your alert list).

Switching it on starts fresh. From then on new work is sent; nothing from the time it was off is sent later, and anything still held from before is marked as not sent. Two exceptions always go out: the notice that the connection was switched off, and the return of the other app’s local stock.

The one case that is genuinely lost

There is a limit, and it is documented rather than hidden.

While an app is not answering, its connection can hold up to 500 messages. Past that, the oldest are given up on. They move to Never delivered, a visible state, never a silent deletion, and the panel says so:

68 messages never delivered. The other app is missing that data.

Refusals, and why they are different

A refusal is not a failure of delivery — the message arrived and was understood, and Floormode declined to apply it. Refusals come back with a reason, and they are counted separately as Rejected.

The refusals a merchant actually meets:

Refusal	Why	Fix
The location is not one Floormode receives for	Nothing here should book goods in at a location you have not handed over	Map or delegate the location, then have the sibling resend
The document has already been updated to a newer version	An out-of-order revision would undo a newer plan	Nothing — it is correct, and nothing changed
The document has no physical lines	There is nothing to receive	Nothing — informational
The document has grown too large to revise safely	Rewriting it would re-announce units already in a bin	Split the document in the sibling

The distinction the panel is careful about: “they have stopped talking to us” and “they are talking and we keep refusing them” look identical from the warehouse floor and have opposite fixes. That is why Received, Rejected and Last message are three separate numbers rather than one health light.

Duplicates

Every message carries an identifier that is unique to the thing it describes. If the same message arrives twice — a retry after a confirmation went missing, a sibling replaying its own queue — the second copy is recognised and ignored, not applied again.

Reports that travel the other way are built the same way round: they carry running totals rather than increments. A second delivery against a purchase order reports the full quantity received so far, not “two more”. A total that arrives twice is harmless; an increment that arrives twice is a wrong number nobody can trace.

Messages the other app sends while it is off here

A switched-off connection holds both directions. Documents the other app sends (a purchase order, a transfer) are not applied while the switch is off. The other app keeps them and sends them again; they land once you switch the connection on. Its exits always land: it leaving, it releasing receiving back to itself, and its confirmations of work Floormode already did.

See Activation for what else switching off does and does not undo.