Architecture · Flows
User and operator flows,
step by step.
Ten diagrams of how Office Unbound is meant to behave for the people who use it and the people who run it — from a normal working session to a Microsoft 365 cutover — with every decision, check, failure and recovery drawn in.
Project status These are planned designs written before implementation. Nothing shown here is available, and the flows will change as the components are built and tested.
How to read the diagrams
Every flow uses the same symbols and the same layout, so a failure looks the same wherever it happens.
The main path runs down the left. Decisions and validation checks are the teal shapes with pointed ends; the path continues downwards on “yes” unless a label says otherwise. Anything that can go wrong branches to the right in copper, and a dashed line shows how the flow recovers — usually by going back to the step that has to be repeated. Dark boxes are approval points, where a person must confirm before anything changes.
The diagrams show intended behavior. They are a way to agree on what the product should do — and to argue with it — before code exists. Where a step depends on a component still under evaluation, it is drawn dashed.
Key
The same eight symbols appear in every flow.
Everyday use
The flows people meet on an ordinary day and on their first day. The aim in all three is that a failure is explained where it happens and has an obvious way back.
Flow A — A normal working session
One sign-in leads to a workspace from which mail, calendar and files open without signing in again. The first check is sign-in itself: a wrong password, an incomplete MFA prompt or a locked account is reported as such, and is recovered by self-service reset or an administrator unlock rather than a generic error. The second check is whether a change reached the server. If the device is offline the change stays on it and syncs later; if the same item was changed somewhere else, both versions are kept.
Flow B — First-time onboarding
A new user arrives through a time-limited invitation and leaves with a verified identity, working MFA and their devices set up. Three checks guard the path: the link must be valid, the identity must be confirmed, and a test MFA code must be accepted before MFA counts as enrolled. Each failure has a named way back — a re-sent invitation, out-of-band verification by the helpdesk, or re-enrolling after checking the device clock. Desktop and mobile setup is optional and can be done later.
Flow H — Desktop file sync
The sync client signs in through the same identity provider as the browser, so organization policy can refuse an unapproved device and say why. Before the first download the client checks that the chosen folders fit on the disk; if not, the user selects less or marks more as online only. After that, changes sync both ways. When one file was edited in two places, both versions are kept and the user decides — nothing is overwritten silently.
More on how sync and offline access are designed: Files and sync.
Provisioning and administration
Creating a tenant, working inside a customer’s tenant, and updating the platform. Each has an explicit approval point, and each records what happened.
Flow C — Tenant provisioning
Domain ownership is proved with a DNS TXT record before anything else is created, and the check can be re-run while DNS propagates. Every choice — identity source, services, document engine, policies — is collected first and checked together in a review that names the setting that failed. Only after the administrator confirms the summary is anything provisioned. If provisioning fails part-way, what was created is rolled back so a retry starts clean.
Flow I — MSP technician access
A technician signs in as themselves, not with a shared customer account, and sees only the tenants assigned to them. Permission is checked on every operation, not once per session. When the role does not allow something, the technician requests approval with a reason, scope and time limit; an approval grants time-limited access, and a refusal changes nothing. Either way the attempt and its outcome are recorded in an audit log the customer can read.
How multi-tenant operation is designed for providers: For MSPs.
Flow J — Customer-controlled updates
An update is installed only when the customer — or an MSP administrator they delegate to — approves it, after reading what it fixes and what it may break. A release with an invalid signature is rejected before review. Rollout goes ring by ring, test before pilot before everyone, with a snapshot before each deployment. If verification fails, that snapshot is restored and the rollout stops; deferring is a legitimate choice, and the advisory stays visible until it is acted on.
Migration
The two longest flows on the page. Both follow the same staged process: understand the source, map it, rehearse, get approval, move in batches, verify. They differ in how the source is reached and what needs converting.
Flow D — Microsoft 365 migration
Nothing moves until access is granted, every identity is mapped and a dry run of the pilot batch matches on counts, sizes and permissions. Items that cannot be migrated go to an exception register with an owner and a decision; they are never dropped silently. Cutover needs the customer’s sign-off for a change window. During migration, failed items are retried and then reported; if final verification fails, mail is routed back to the source, which was never modified.
The stages in detail: Migrating from Microsoft 365 and the migration process.
Flow E — Google Workspace migration
The same structure as Flow D, with Google-specific checks. A message can carry several Gmail labels but sit in only one folder, so the administrator chooses a label policy before mail moves. Docs, Sheets and Slides are converted to Office or OpenDocument formats, and what cannot convert — Apps Script, Forms, add-ons — is listed in a conversion report. Shared Drives become team folders. Chat history through a Vault export is optional and still under evaluation.
The stages in detail: Migrating from Google Workspace.
These flows describe planned tooling. What can be read from each source depends on the APIs Microsoft and Google expose, and Teams and Google Chat history in particular may not be fully exportable. Conversion fidelity for complex documents will be stated after testing, not assumed.
Document engines
Office Unbound is designed to work with either Collabora Online or ONLYOFFICE Docs. Choosing one is a deployment decision, made once in configuration; each engine and edition brings its own limits and license terms, and changing later is a controlled maintenance operation.
Flow F — Selecting a document engine
The choice comes first, then a review of that engine’s license terms, edition limits and file-format behavior, because these differ and matter for the deployment. The endpoint is configured and then tested by actually opening, editing, saving and co-editing files. A failed test names its cause — TLS, the shared secret, network reach or version — and the administrator corrects the configuration and tests again. Activation is a separate, explicit confirmation.
Flow G — Switching document engines
Switching is a scheduled administrative cutover, not a live swap: open sessions are drained in an approved maintenance window before the integration is pointed at the new engine. Blocking compatibility risks stop the switch before it is scheduled, and an engine that fails staging validation means the switch is called off. Because documents are stored in the file service rather than inside the engine, rolling back after a failed test means pointing the integration back; no files need restoring.
Why both engines are supported and how they differ: Document engines.
Tell us where these flows are wrong
If you run Microsoft 365, Google Workspace or a hosting practice today, your experience of what goes wrong is exactly what these designs need.