Governance at Scale: What Our Webinar Audience Really Wanted to Know

Last week's webinar, "The COE Is Dead. Who's Governing Your Power Platform Now?", generated a lot of questions from attendees across financial services, professional services, government, and enterprise IT. The volume and specificity of those questions told their own story: organisations are not abstract-worried about the COE deprecation. They are working through concrete operational problems right now.

This post covers the questions that came in, grouped by the themes that kept surfacing throughout the session. If you want the strategic context first, read Who's Governing Your Power Platform Now That Microsoft's COE Starter Kit Is Gone? before diving in here.

How Deep Does the Inventory Actually Go?

The most common category of questions was about the inventory wihtin Rencore Governance: what it captures, how current it is, and whether it covers the parts of the Microsoft ecosystem that matter most.

On freshness: the inventory withing Rencore is not real-time. Rencore Governance uses the same Graph API endpoints that any Microsoft-connected application uses, and Microsoft applies throttling limits to those calls. As Rencore Governance gathers a lot of information down to the individual file level across many different services (Teams, SharePoint, OneDrive, Entra ID, Power Apps, Power Automate, Power BI, Copilot, Copilot Studio etc.) getting all this data live for larger Microsoft 365 tenants is technically not possible for any vendor apart from Microsoft. What differentiates a governance-grade inventory from a one-time scan is how it handles updates. Rencore reads audit logs and change events continuously, so the data stays current without relying on full rescans to optimize data freshness against the available API calls. In practice, for governance purposes, this is not a limitation that affects outcomes. Governance is about enforcing guardrails automatically, not watching a live feed. In reality the data is usually up to 24h old, even in tenants > with 100k+ users. On the contrary to other solutions in the space. Rencore allows you to configure update frequency on a very granular level to make sure that the most relevant data is as fresh as possible.

On depth: one attendee asked whether the data source is the same as the COE. It is. Both tools read from the Graph API. The difference is in the data model built from that source. Rencore collects metadata down in a much finer granularity, including permissions, related metadata in other objects and maps the relationships between objects also across services. That means an administrator can see not just that a flow exists, but also who owns it, which environment it runs in, what connectors it uses, which SharePoint site it reads from, and whether that site has a sensitivity label applied.

On agent coverage: two questions came in specifically about agents. Copilot Studio agents are fully supported today, including creation metadata, knowledge sources, topics, actions, and conversation activity. Where the relationship model becomes particularly useful is in cross-service risk detection: an agent consuming a SharePoint site with a confidential sensitivity label, exposed through a Teams channel that includes external guests, is a compliance risk that requires joining data points across three separate services. That is exactly what the Rencore data model is designed to surface.

Microsoft Scout agents and Microsoft Cowork are not yet supported because Microsoft has not released public APIs for them. That said, Microsoft released an API for Agent Builder agents approximately three weeks before the webinar, and Rencore is actively adding that coverage now. As Microsoft continues to expand its agent ecosystem, the governance surface expands with it. The pattern of Microsoft releasing new capabilities before governance tooling catches up is not new, but it is accelerating.

Policies, Automations, and Extensibility

Several attendees came from organisations that had built custom governance actions on top of the COE Starter Kit and wanted to know whether those workflows could be replicated. The answer is yes, and the mechanism is Rencore's automation engine.

The Rencore engine is not built on Power Automate. That was a deliberate architectural decision. Using Power Automate to govern Power Platform creates a dependency on the very platform being governed, which introduces reliability and licensing complications as well as the risk of a disconnect between identification of the policy violation and the resolution. Rencore Governance's automation engine is independent, does not require Power Platform licences, and can trigger Power Automate flows via webhook if an organisation wants to bridge the two systems.

On the question of requiring creators to register or seek approval before building: this is achievable through a combination of policies and the Rencore Teams app. When a new app or flow is detected, a policy can trigger an automation that notifies the creator, routes an approval request, and captures the response. What is not possible is intercepting the creation at the point it happens inside Power Apps or Power Automate, since Microsoft does not expose that event for third-party tools to hook into. Provisioning flows and apps through Rencore, which would allow pre-creation approval, is on the roadmap but not yet available in production.

Notifications can be sent via email, Teams messages, or webhook to any external system. The message content supports dynamic placeholders populated with inventory metadata, so notifications can include specific details about the resource triggering the policy. For anything not covered natively, a webhook or HTTP request to an Azure function covers the gap.

A public API for Rencore Governance is in development. The initial version will allow external systems to trigger automations, which addresses the use case raised by one attendee: a registration system in an external platform that, once an asset is approved there, kicks off a compliance workflow inside Rencore. Throttling is a practical consideration here, one Rencore faces for the same reasons Microsoft does, so the API will launch scoped to automation triggers rather than direct inventory access. That scope will expand over time.

Ownership, Lifecycle, and the Offboarding Problem

A question that generated follow-up discussion was whether flows and apps can be transferred when a user leaves the organisation. Ownership can be added or changed on standard Power Automate flows (not just solution-aware flows) through an automation. When combined with a lifecycle policy, this means an organisation can automatically detect flows whose owners are no longer active, route a reassignment request to a designated admin or group, and document the resolution without manual administrator intervention. The same logic applies to any resource with an owner: Teams, SharePoint sites, Power Apps, agents.

Another practical scenario raised was dependency checking before deletion. Before removing a SharePoint site, an administrator needs to know which flows, reports, or agents depend on it. That dependency graph is queryable in Rencore, and a policy can be built that surfaces those connections and requires confirmation or approval before any decommission action proceeds.

The question about app criticality is worth addressing in detail because it reflects a genuine governance maturity challenge. Rencore can capture metadata about an app or flow, and an automation can be configured to prompt the owner with a structured question, for example asking whether the process is business-critical, and feed the response back into a custom metadata field. That custom metadata can then be used as a condition in future policies. It requires design work, but the capability is there. The same mechanism can be used to collect cost centre attribution, business unit ownership, or any other organisational taxonomy that needs to map onto the technical inventory.

Lifecycle management for Power Platform environments, including provisioning, is in active development. Teams, SharePoint, Viva Engage, and Planner provisioning are live. Power Platform environment provisioning is coming. Capacity assignment to environments, for example allocating Copilot credits or Dataverse storage, is not yet available and depends on Microsoft exposing the relevant APIs.

Run history data for Power Automate Flows is retained indefinitely by Rencore. Microsoft's native Power Automate run history is cleared after 30 days. For organisations that need to satisfy audit requests covering periods longer than a month, that distinction matters considerably.

Data Residency, Security, and Self-Hosting

Multiple attendees asked whether data leaves their tenant and where it is stored. This question came in from attendees across financial services and government sectors, which is consistent with where data residency requirements tend to be strictest.

Rencore Governance collects metadata only. No file content, no message bodies, no user-generated content is transferred. The metadata that is collected moves into a dedicated Azure resource group per customer, encrypted with a customer-specific key. The consent model is granular: administrators can grant read-only access per service initially, and add write permissions incrementally as they extend their use of automations and lifecycle actions. For Power Platform specifically, Microsoft does not yet provide application permissions for third-party tools, so a dedicated Power Platform administrator account is required for that service, separate from any global administrator role.

Hosting regions currently include the US, Germany, Switzerland, the Netherlands, and Australia, with additional regions being added. For organisations with regulatory requirements that prohibit connecting to a SaaS service entirely, self-hosting in the customer's own Azure subscription is supported. This is most relevant for financial institutions and government organisations operating under data sovereignty constraints, including those subject to DORA or NIS2 obligations.

Multi-Tenant, Licensing, and the Scope Question

For managed service providers, Rencore Governance is multi-tenant capable. Each customer can be a separate workspace, and within a workspace, multiple tenants can be managed together. The administrator operating the tool does not need to be a user in the tenants being managed, since Rencore operates via application permissions granted in each customer tenant. That means an MSP administrator can log into Rencore with their own organisational account and move between customer environments without holding accounts in each one. Policies, reports, dashboards, and automation configurations can be exported from one environment and imported into another, which makes building standardised governance templates across a customer portfolio practical.

One attendee made a point worth highlighting: the tool felt like more than a Power Platform solution. It is. The same inventory, policy, and automation framework covers Teams, SharePoint, Exchange, Entra, OneDrive, Viva Engage, Planner, Power BI, Copilot Studio, and the full Power Platform. The governance problems that the COE deprecation surfaces are real, but they are also symptoms of a broader challenge: as Microsoft 365 grows in complexity, the need for a unified governance layer across all of its services, not just Power Platform, becomes increasingly difficult to ignore.

Licensing is per Microsoft 365 licensed user, structured in three modules: a collaboration pack covering core M365 services, a Power Platform module adding Power Apps, Power Automate, and Power BI, and a Copilot and agents module covering Copilot Studio and Agent Builder. Features like provisioning can be added or excluded depending on requirements. For a ballpark number specific to your organisation's size, reach out directly.