Dependency diagramsThe dependencies, drawn
A list of connectors tells you what an app binds. It does not tell you the shape of the thing, and shape is what somebody arrives with: what IS this, and what comes with it if I move it. Every app and every flow carries a diagram of its own relationships, built from the same resolved dependencies as the rest of the product — including the ones Microsoft’s APIs never state directly.
- The object in the centre, what reaches it on one side and what it reaches on the other — one picture instead of three tabs
- Three levels, not two: a connector is not a destination, so each one opens into the tables, views and lists it actually touches
- The solution box — when an object is solution-aware the whole picture is drawn inside it, because that box is the unit that travels
- Premium connectors marked where they sit, since every user of the app needs a licence that covers them
The box is the migration unit
The same diagram for an app that IS in a solution: the whole picture sits inside a dashed box carrying the solution’s name and whether it is managed. That box is what an export actually takes. Here all three flows this app calls are inside it, so the app travels whole — an app outside a solution travels as a pile of loose parts instead, which is most of what a migration costs. Branches fold away when the estate behind one connector is larger than the question being asked.
The same picture, from the flow’s side
Flows get the mirror of it: what starts the flow on the left — a schedule, an event, or the apps that call it — and what it reads and writes on the right, taken from the flow definition step by step rather than from the connection. Opening an app and then opening one of its flows should feel like walking one step along the same graph, not arriving at a different drawing.
Every screen here is a live demo tenant
Contoso is sample data, generated rather than scanned — but it renders through exactly the same code as a real tenant, so what you walk around is what you would get.