Connected systems
What information comes in, what goes out, and what the business notices when each connection is unavailable.
What information comes in, what goes out, and what the business notices when each connection is unavailable.
Microsoft 365 mailboxes
| What comes in | Mail from enrolled Flowtech mailboxes: subject, body, sender and recipients, date, and all attachments — including files nested inside forwarded messages |
| What goes out | Replies and quotations sent from FlowOS. The shared office mailbox is the reply-to even when the engineer is the from |
| Which side is authoritative for inbound | The mailbox. FlowOS holds a copy of what was received |
| How current | As current as the last successful delta. Each mailbox has its own cursor |
| When unavailable | Sync records the error and consecutive failures. Everything already held stays fully workable |
The mail body is taken in its formatted form and converted here, because letting the mail service flatten it loses table structure — an enquiry listing three instruments in a table would otherwise arrive as one value per line.
Sent Items: the internet message id of mail FlowOS sends is recorded. Without it, delta sync would ingest our own quotation as a new inbound document. Combined with scoping the delta to Inbox.
Entra ID
| What comes in | Who the person is, for Microsoft sign-in |
| What FlowOS owns | Office, roles, grants, password invites. Office is not read from Entra |
| When unavailable | Microsoft sign-in fails. Password accounts still sign in. Existing sessions continue until they expire |
The language-model service
Used for the reading that cannot be done by rule: labelling each message, judging whether a message changes anything technical, pulling out job references, splitting an enquiry into line items, and extracting each line’s parameters.
| What goes out | The text of the mail and the attached documents |
| What comes in | The labels, the line-item split, and the extracted parameters |
| Which side is authoritative | FlowOS. Nothing is stored on the other side that we read back |
| When unavailable | Message labelling fails safe — the message is treated as an enquiry, so an RFQ is never hidden by an outage. The reading of an enquiry fails — the case is marked failed and stays in the queue. Other work continues |
Several choices exist to keep this connection’s use down — a single-instrument enquiry takes a fast path, a reply that changes nothing does not trigger a re-read, and one call covers all the line items in a category.
Customer enquiry text and datasheets are sent to this service. Where it is hosted, and under what agreement, is a question for the business.
The document reader
Converts attachments to text, including character recognition for scanned pages. Recognition runs on the deployment.
| When unavailable | Scanned documents report that recognition was skipped, rather than reporting the document as blank. Everything else still converts |
The ERP of record
| What goes out | Confirmed sales orders, after PO-vs-quote verification |
| What comes in | Acceptance, rejection, and reconciliation state per attempt |
| Which side is authoritative for stock and dispatch | The ERP |
| When unavailable | The handoff row stays in the queue and can be retried. Postgres is truth; the queue message is transport |
The defect tracker
The floating Report a problem control sends a defect with the page they were on and their browser details. When unavailable, they are told it did not send. Nothing else is affected.
Not connected
| System | Position |
|---|---|
| Stock / dispatch / invoicing | Stay in the ERP after handoff |
| IMAP as a second mail path | Mail comes from Microsoft 365 Graph |