Every environment, including the ones you forgot
Most tenants have more environments than anyone can name, and the ones nobody can name are where the risk is. Every environment the tenant has, with the governance flags that matter, and a tabbed view of everything inside each one — apps, flows, solutions, tables, connections, connection references and custom connectors.
- Type, region, runtime state and creation date for every environment
- Dataverse URL and version where a database exists, and a clear dash where it does not
- Managed Environment flag, so the governance gap is a column rather than a conversation
- Per-environment counts for apps, flows, solutions, tables and connections — sortable, so the outliers surface
One environment, summarised
Eight figures and the details behind them. Apps split canvas against model-driven, flows split started against total, solutions split managed against unmanaged, and a makers count — distinct owners of an app or flow — which is usually the number that surprises people. The top connectors panel is scoped to this environment, so it answers which bindings would have to be recreated if it moved.
Apps
Every app in this environment with its owner, type, sharing reach, connectors and the SQL databases behind it. The same table as the tenant-wide app list, scoped — so a filter you built once works in both places.
Flows
Cloud flows with their trigger, run state and connectors. A stopped flow in a production environment is either deliberate or forgotten, and the state column is the fastest way to find out which.
Solutions
Managed and unmanaged solutions, their publisher, version and component counts. Unmanaged solutions in production are the ones that will not deploy cleanly anywhere else, and they are called out rather than buried.
Dataverse tables
Every table, custom and standard, with its logical name, ownership type, column count and whether auditing and change tracking are on. Open one for its full column list — which is the documentation nobody ever has when they need it.
Connections
Every connection in the environment and — the part that matters — the account it authenticates as. A production flow running as a named individual is a resignation away from an outage, and this is the column that finds them.
Connection references
The solution-aware bindings, with the connection each one currently points at and how many flows use it. The difference between a connection reference and a direct binding is the difference between a solution that can be re-pointed at deployment and one that has to be rewired by hand.
Custom connectors
Connectors written in this tenant, with their backend host and who created them. These are the dependencies that do not come with a solution export and that usually have no owner left — which is why they get their own tab rather than a row in a list.
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.