Microsoft Copilot
The rules you want to run are written in the wrong language
Ask a governance team which rules they wish they could run, and the answer rarely uses solely Microsoft 365 vocabulary. It uses the language of the business.
Typical requests sound like this. They want external users out of department teams. They want client project rooms held more tightly than internal ones. They want storage costs to land with the business unit or project that creates them. They want a workspace closed when its project closes.
None of those rules is exotic, and each one fails for the same reason. Microsoft 365 describes a workspace by its owner, its sensitivity label, its group type, and its name. It has no idea which client a workspace serves or which cost center pays for it. The intent is there. The words the rule needs are missing.
Teams have been translating by hand
Governance teams have not waited for a fix. They encode meaning into names, so “PRJ-4021 Contoso Migration” carries a project code a rule or report can match. They build side databases and SharePoint lists to hold the business fields IT needs to fulfil their use cases.
Both approaches prove how much the business context matters and both are fragile. A renamed team silently drops out of the rule written for it. A side database stores values but cannot act on them, and it usually depends on one person remembering to keep it alive.
The cost is easy to underestimate because it builds slowly. Every new rule needs a new convention. Every convention needs someone to police it. Every reorganization breaks a few of them, and nobody finds out until an audit or an incident shows the gap.
Over time, the governance team spends more effort maintaining the translation than running the rules it was built for. The result is a governance model that knows a great deal about Microsoft’s objects and very little about the business they serve.
AI raises the price of that gap
This used to be an efficiency problem, but AI turns it into a risk question.
Microsoft 365 Copilot answers from the content users can already reach. So the governance decisions that matter most now sound like business decisions. Which client material should be held tightly? Which department spaces should never include guests? Which project rooms should be closed before an assistant surfaces them a year later?
A governance program that cannot tell a client room from a community site cannot answer those questions, however strong its technical controls are.
Bring the business into the governance model
The fix is to stop translating and centrally maintaining the data. Put the business’s own terms into the governance layer, keep them current from the systems and people that own them, and let every rule use them directly.
We laid out three principles we think matter.
Business context should come from its source. Finance owns cost centers. HR owns departments. Values retyped into workspaces are wrong the first time something changes.
Owners should be asked only for what no system knows. And they should be asked inside work they already do, such as a periodic review.
Every field should earn its place. A field that only sits in a column gives you a tidier inventory. A field that drives a rule, a report, or a review gives you a governance model.
What changes when governance speaks the business’s language
The first change is in the rules themselves. They get shorter and more precise, because they test the thing the business cares about rather than a proxy for it. A rule written against “Workspace type is Client project” survives renames, reorganizations, and new naming standards.
The second change is in who can read the output. A report grouped by cost center or client means something to finance, legal, and business unit leaders. Governance stops being a set of IT dashboards and becomes evidence other teams can use or can be used by IT to communicate more clearly with those.
The third change is in how fast you can respond. When a new requirement arrives, such as a client contract with stricter handling terms, the question becomes which workspaces carry that client. You can answer it in minutes instead of starting a discovery project.
What this looks like in Rencore Governance
That thinking shaped Custom Metadata in Rencore Governance. Customers define their own fields and reference lists, such as workspace type or cost center. Reference lists stay current from a scheduled feed, and review steps ask owners only for the values that are missing.
Those fields then work wherever Rencore already asks which workspaces you mean: policies, segments, reports, and reviews. “Remove external users from department teams” stops being a wish and becomes a policy.
We know that every business is different. That is why Custom Metadata is true to its name: truly customizable. You can extend existing items like Teams using custom properties and add custom relations, while also bringing in full objects like Projects or Cost Centers from your business.
Start with the rule you can’t write
Your team can probably name one without thinking. Everyone agrees on it, and nobody can enforce it, because the system does not know what the rule is talking about. That rule is the right place to start. Early testing showed that use cases can be incredibly sophisticated, so it’s best to start small with a well-scoped use case that everyone understands and that has a clear trajectory.
