Sync, merges & conflicts
When several people — or several of your own devices — work on one cloud project, their changes eventually meet. This page explains what happens when they do: what combines on its own, what needs a decision from you, and what each choice costs. The rule underneath all of it: nothing anyone added is ever discarded unless someone deliberately chose to discard it.
If you're looking for the basics of saving (the pill, the Save button, autosave), start with Save and sync.
How a save lands
A cloud project is a checkout: you edit on this device, and Save to cloud pushes your changes. Every save states which cloud revision it was built on. If the cloud still holds that revision, the save is accepted. If someone else saved in the meantime, your save is refused instead of overwriting their work — and the resolve dialog opens so you can combine the two.
That refusal is the whole safety mechanism. There is no window in which the last writer silently wins: either your save is built on the latest revision, or you are shown exactly what happened in between. The quiet background syncs (on editor blur, tab-hide, idle, and navigation) go through the same check — they never bypass it, and when they meet newer remote work they stand down and flag Remote newer instead of opening a dialog mid-edit.
Every accepted save also becomes a snapshot in the project's version history, so even a decision you regret can be walked back.
What merges on its own
Most simultaneous work never raises a question, because most simultaneous work is about different things. These combine automatically, and both sides keep everything:
- Different elements. You add a container, a teammate adds another — both arrive. Editing two different elements never collides either.
- Different connections. Each connection between two elements is its own record — relabeling one while a teammate adds another combines cleanly.
- Additions to the same diagram. Two people placing new elements on one diagram both keep their cards; the diagram shows the union.
- Different diagrams' layouts. Each diagram's arrangement (positions, boundary frames, hand-routed lines) is its own unit — arranging different diagrams never collides.
- Working from an old copy. A device that hasn't loaded for days can still save. Its staleness is not read as deletion: everything others added in the meantime stays, and its own additions join them.
Two things are deliberately never fought over:
- Geometry. If both of you moved cards on the same diagram, your arrangement wins on your screen without a prompt — there is no useful question to ask about two layouts, and either of you can re-drag in seconds. Text you typed (a renamed card at a collapsed level, a rolled-up line's label) is treated as content and gets real conflict handling.
- View state. Panel widths, export presets, the deployment level you're looking at — these are device-local. Loading a teammate's save never overwrites yours.
When a conflict is raised
A conflict means both sides changed the same thing — you renamed an element to Storefront while a teammate renamed it to Frontend. The app cannot know which is right, so it asks, and it will not let the save proceed until you've answered.
The thing being compared is the whole record — an element, a connection, a decision. If you both edited the same element, it is contested even when you touched different fields of it: the conflict row shows exactly which fields differ, so you can see at a glance whether your two edits actually overlap. A description counts as one field — two people editing different perspective sections of one element's description is still a conflict over that element, not two separate edits. When you split writing work, split it by element, not by section within one element.
A deletion is related but different. If a teammate deleted something you haven't touched, the deletion goes through — but the dialog lists it in its own removals section so it cannot slip past unseen. If they deleted something you've since edited (or the other way round), that's a real conflict: the row says so, and choosing Mine keeps the record while choosing Theirs deletes it.
The resolve dialog
When your save is refused, a dialog titled "This project changed on the remote" shows everything that happened between your copy and the cloud, grouped so the risky parts can't hide. Closing it changes nothing — your edits stay on this device until you choose.
Conflicts — decide each one
Conflicts come first. Each row names the element and states how many fields differ; opening it shows a field-by-field table of your value against theirs — exactly the fields that differ, nothing else. Pick Mine or Theirs per conflict. If there are many, decide the remaining applies one answer to everything you haven't picked yet.
A pick applies to the whole contested record: choosing Theirs takes their version of that element outright, including any field only you had changed — which is exactly what the field table exists to show before you choose. What a pick never touches is anything outside that record: every other element, connection and diagram that merged cleanly still merges, whatever you pick here.
Removals — always visible
Anything that would be deleted gets its own section, never collapsed, naming each item. Every other effect of a merge is visible in the result afterwards — a removal is visible nowhere, which is why it is the one thing the dialog refuses to let you skim past.
The three ways out
| Action | What it does | What it costs |
|---|---|---|
| Combine (recommended) | Applies both sides' work plus your conflict picks | Nothing that wasn't explicitly decided |
| Keep my version | Replaces the cloud with your copy, wholesale | Everything others saved since your last load — the dialog states the count and asks you to confirm |
| Take the remote version | Replaces your copy with the cloud's, wholesale | Every local edit you haven't saved — and unsaved local edits exist nowhere else, so the dialog offers Save my version to a file first before you commit |
Combine stays disabled until every conflict is decided, and it refuses to produce a combination that would break the project (for example, one side deleting a system while the other added a container inside it) — you'll be asked to resolve differently rather than push a broken model.
After a combine, a short summary states what the merge did — how many changes applied, how many you decided — and the merge is recorded in the project's audit log, with version history one click away if you want to inspect the result against what came before.
What can never happen
These are the guarantees the sync is built on — the things that are prevented rather than merely discouraged:
- A save never silently overwrites someone else's save. Every push is checked against the revision it was built on; a mismatch always surfaces the dialog.
- Being out of date never deletes anything. A stale device's save adds its work to everyone else's; only a real deletion, made by a person, removes an element.
- A stale tab can't push old content over new. If another tab or window moved the project underneath an open editor, the editor catches up before writing — and if a change couldn't be saved, a standing notice says so rather than pretending it landed.
- A refused save says so. Whether the browser ran out of storage or the write was redirected, "saved" is only ever shown when the work actually persisted.
- Reading a published link never writes. Someone browsing your read-only link — including you, on another device — cannot modify the project or their own local work by doing so.
- Your screen never changes by itself. A teammate's save flips the pill to Remote newer; the content in front of you changes only when you load it — Load latest, a Save with nothing to save, or reopening the project. Two people editing the same element therefore always meet in the resolve dialog, never in a silent last-writer-wins.
- Wholesale choices are counted and confirmed. Keep my version and Take the remote version both state how many changes they discard, and ask, before acting.
If something still goes wrong
- Restore from version history. Every accepted cloud save is a snapshot — up to about 100 recent saves, and snapshots also age out, so assume restore points older than 7 days may be gone. Open the project detail page, click Version history, pick the revision, restore: the old version loads as unsaved changes for you to review and Save forward, never as a destructive rewrite. Note that snapshots hold what was pushed: local edits that never reached the cloud aren't in them, which is exactly why Take the remote version offers the file export first.
- Restore from a backup file. If you exported JSON — before a big restructuring, or from the dialog's escape hatch — create a new project From file and you have the exact state back. See JSON backup and import.
- Check the audit log. It records who saved and who resolved what, which usually answers "where did that change come from".
Working well together
None of the machinery above needs ceremony, but a few habits keep the dialog rare and small:
- Save at milestones, not at the end of the day. Small, frequent saves mean small, obvious merges — and other people's tabs pick your changes up sooner.
- Watch the pill. Remote newer with no local edits means one click (Load latest) puts you on the current version before you start editing — the cheapest merge is the one that never happens.
- Split by diagram where you can. Everything merges, but two people arranging the same diagram will each keep their own layout locally — agree who owns an arrangement pass.
- One author per element at a time. An element's description — perspective sections included — is contested as a whole, so divide writing work by element, not by section inside one element.
- Don't park unsaved work. A tab left dirty for a week meets a week of everyone else's changes at once. It will still merge safely — it's just a bigger review than it needed to be.
- Export before you take a cliff. If you're about to Take the remote version and your local edits matter, use the offered file export. It costs seconds.
Where next
- Collaborate on a cloud project — the full list of independently-tracked parts, and the working habits that keep merges small.
- Manage projects — saving, version history, backup and restore.
- Share & collaborate — invite teammates, roles, published read-only links.