How to share an architecture diagram read-only
Give people access to a diagram at the level they actually need: a link for a reader, an embed for a page that should always show the current version, named collaborators for the people who work on it, and presentation for a live audience.
When this is useful
- A diagram has to go to people outside the team — a supplier, a security reviewer, an executive — and none of them should be able to edit it.
- A wiki page carries a screenshot of an architecture that has moved on, and you want it to stop happening.
- You are presenting a design and do not want the editor interface on the screen.
Before you start
- A diagram in a state you are willing to have read. A share link shows the model as published, so publish the version you mean.
- Sharing enabled for your organisation. It is a capability that can be deliberately withheld, and where it is withheld the menu items are inactive rather than hidden.
Step 1: Decide which of the four you need
A share link is for reading — the viewer opens the diagram, no account required. An embed puts a live view inside another page. Presentation is for a live audience. Collaborators is for the people who work on the diagram with you, and is the only one of the four that can grant edit rights.
These are separate deliberately. Who can see, who can edit and who can approve are three different questions, and answering them with one setting is how people end up with edit rights nobody intended.
Step 2: Create the share link
Generate a share link from the diagram menu. It opens a read-only view of the published diagram: the viewer sees the model, not the editor, and does not need to sign in.
Diagram ▸ Share link
Step 3: Embed it where people already read
An embed link renders the live diagram inside another page rather than a picture of it. The point is that the page stops being wrong the moment the architecture changes, which is the failure mode of every exported screenshot.
Step 4: Name the people who work on it
Add the people who need to edit or review to the team and collaborators list, with the access each of them needs. If the diagram needs formal sign-off rather than comments, run it through the approval workflow — approving is a separate right from editing.
Diagram ▸ Team & collaboratorsDiagram ▸ Approval workflow
Step 5: Present it live
Present in flow mode to walk an audience through the diagram in the order you defined, without the editor on screen. The audience sees the diagram; they do not get edit access by being in the room.
Page ▸ PresentPage ▸ Flow (default)
What happens next
The link keeps working as the diagram changes, which is the intended behaviour: the reader gets the current architecture, not the one that was current when you sent the email.
If you need a frozen copy instead — for a contract, an audit pack, a point-in-time record — export it rather than sharing it.
Example
An integration design that a supplier had to review: share link in the email, embed on the internal wiki page, and named collaborators for the two engineers actually editing it. The supplier never had an account and never needed one.
Tips
- Share the link, not a screenshot, whenever the reader might come back to it a second time. The second reading is where a screenshot has usually gone stale.
- Use the approval workflow rather than collaborator access when what you want is a decision recorded, not a conversation.
- A read-only viewer cannot edit the model. That is the guarantee — it is enforced on the record, not by hiding the toolbar.
Limitations
- Sharing, comments and the approval workflow are each separately enabled, so which of these steps you can complete depends on your organisation.
- Share, present and embed views are read-only by design. There is no share mode that grants editing — editing is granted by adding a collaborator.