M365 Architecture Canvas

Diagramming a Microsoft 365 solution

Most M365 architecture diagrams draw the wrong thing. They show which products are involved, which everyone already knows, and leave out the boundaries that actually determine whether the solution works: who it runs as, where the data sits, and which licences it assumes. The canvas above is for the second kind of diagram — drag out the components, connect them, and label the connections rather than the boxes.

Draw the identity, not just the arrow

The single most useful thing to put on an M365 diagram is what each hop runs as. A Power Automate flow does not run as the person who triggered it; it runs as the owner of the connection it uses. That is why a flow works for its author and silently fails, or worse quietly succeeds with the wrong permissions, for everyone else. An SPFx web part calls Graph as the signed-in user; an Azure Function calling Graph app-only has no user at all and no site restrictions unless you added them. Label every arrow with the identity and the failure modes become visible on the page.

Boundaries worth drawing

• Tenant. Anything crossing it needs guest access, B2B, or an explicitly multi-tenant app registration, and each of those is a separate approval conversation.
• Site collection. Permissions, content types and navigation mostly stop here. Hub association shares some of it and not the rest, which is a frequent surprise.
• Connection. In Power Platform the connection is the security boundary, and it is owned by a person. A solution whose diagram does not name connection owners has an offboarding problem waiting in it.
• Licence. Premium connectors, Dataverse and AI Builder change who can use the thing. Marking premium components on the diagram avoids designing something the audience cannot be licensed for.

Name the components as they are named in the tenant

A diagram that says “Approval Flow” is much less useful than one carrying the actual flow name, the site URL and the app registration's display name. The person reading the diagram at 2am is trying to find the thing in a portal, and a generic label makes them search. The same goes for lists: the internal name earns its place on the diagram, because that is what the code refers to.

Keep it next to the solution

Architecture diagrams rot faster than code because nothing fails when they go stale. Export the canvas and commit the image alongside the solution, so it is reviewed in the same pull request as the change that invalidates it. A diagram that lives in someone's downloads folder will be wrong within a quarter and trusted anyway.