Diagrams and workspace views

Diagrams help you move from raw infrastructure data to a view that people can discuss. Use them when you need to explain resource shape, dependency paths, and review context quickly.

​

Architecture view

Use the architecture view when you want the broad shape of a project:

• resource groups and major resources
• service boundaries
• topology and layout
• resources that need architectural review

This is usually the best first diagram for stakeholders because it answers “what exists?” before it asks “what depends on what?”

​

Dependency view

Use the dependency view when the review depends on relationships:

• upstream and downstream resources
• dependency paths that affect risk or blast radius
• resource chains that make a design harder to change
• differences between expected and actual topology

Dependency views are most useful during engineering review, incident follow-up, or pre-deployment checks.

​

Code and diagram context

For IaC-backed projects, diagrams are strongest when they stay close to the source files. Use the workspace editor to compare:

• the selected resource in the diagram
• the source template or generated ARM JSON
• report findings attached to the same project
• the latest project status

That context matters because the right fix may live in the code, not in the diagram.

​

Diagram markup

Use drawing tools when you need to explain a path, proposed change, or review question in the diagram itself.

​

AI-assisted diagram review

Use diagram context with an assistant when the question depends on multiple resources or relationships.

• Ask about selected resources instead of describing them from memory.
• Use the visible relationship path as the grounding context.
• Keep the diagram open while reviewing the generated explanation.

​

Sharing and embedding

Diagrams can support review outside the core workspace when the project is appropriate to share.

• Use share links for read-only review.
• Use embed links when the diagram belongs inside another internal surface.
• Review the project content before publishing a public or broad internal view.

Shared and embedded views should be treated as read-only communication surfaces, not editing modes.

​

What to avoid

• Do not assume a diagram is current if the project has not synced or reports have not rerun.
• Do not use a public share view when private graph data is required.
• Do not treat architecture and dependency diagrams as interchangeable; they answer different questions.

​

Next step

Use Projects to understand the workspace model, or Headless diagram image downloads when an agent or CI job needs diagram image bytes directly.