Power Platform governance that actually runs
The CoE has standards. Nobody checks them. The gap between "we wrote it down" and "it actually happens" is where every embedded secret and every silent breakage lives.
In 30 seconds
- The CoE wrote the standards. Nothing enforces them, so embedded secrets and silent failures ship anyway.
- Each rule becomes a check that runs against every flow on a schedule and names the documentation it rests on.
- Findings go to the owner with the fix. Exceptions need a named approver and an expiry date. The release gate reads the results.
The full note follows, for when you want the detail.
Examples come from the Flow Trace demo estate, RautingTech's own test environment. No client data or client work is described.
Every CoE lead has a version of the same document: a page of rules that flows are supposed to follow. Every flow needs a failure path. No secrets pasted into a definition. No personal accounts holding a connection a whole team depends on. Work order triggers filter by the columns the team actually agreed matter, not whatever a maker typed first.
Nobody reads that page while building a flow. Why would they — nothing checks it, nothing blocks a bad flow from shipping, and the only time the standards document comes up is after something has already broken and someone goes looking for what should have stopped it. Standards that exist only as documents are, functionally, standards that don't exist.
Turning the document into something that runs
Flow Trace's rules and Fix list exists to close exactly that gap: not a new standards document, but a place where the standards the CoE already wrote become checks the tool actually evaluates, against real flows, continuously.
Part of that is a built-in catalog — nine checks the lint engine already runs on every flow definition, each one promoted to a switchable control with a category and, more importantly, a citation. "No embedded secrets" is blocking by default: a key or an Authorization header pasted into a definition is visible to every maker who opens it and every export that copies it, and there's no argument for shipping that. "Connection references must be bound" is blocking by default too: an unbound reference fails every dependent flow the moment it activates — the exact breakage a comparison across environments catches after the fact, and a control catches before it ships.
The other half is the part that actually makes this a governance tool and not just a lint report: curated controls the CoE writes itself. The standing example is the work-order rule — point a control at every table whose name matches "workorder," and require that its trigger filter by one of an accepted set of columns, say owner, territory, or priority, whichever the CoE actually decided matters. Write that once, and it stops being a line in a wiki page nobody opens and becomes a check that runs against every flow touching those tables, forever, with no maker having to remember it exists.
Where the authority comes from
What keeps this from collapsing into "the tool's opinion versus the platform's facts" is that every single check names where it comes from. A platform-basis check means Microsoft's own API or validation will reject the thing outright — not a judgment call, an actual failure. A documented-basis check means Microsoft Learn calls the pattern out as something to avoid, though the platform still permits it. A governance-basis check is the CoE's own authored rule — not Microsoft's, and Flow Trace doesn't pretend otherwise — but it's a deliberate decision the organization made on purpose, and it's still allowed to block a release if the CoE marked it high severity when they wrote it. An opinion-basis check is Flow Trace's own judgment, always advisory, never a blocker, full stop.
That distinction is what lets a CoE's home-grown work-order rule sit on the same page as a Microsoft platform fact without either one borrowing authority it hasn't earned. Nobody has to take Flow Trace's word for any of it — every finding on the page can be checked against its citation without leaving the app.
What actually shows up
The findings aren't a static inventory sitting around waiting to be reviewed once a quarter — they're assembled fresh from what the last ingest cycle already captured, so the page only shows what's currently true. One finding worth sitting with: an embedded secret, a literal API key pasted into an HTTP action's headers, caught only in dev. That's exactly the environment where it has to be caught, because the secret gets scrubbed out before promotion — which means by the time that flow reaches QA, the evidence that it was ever there is gone. Catch it downstream and there's nothing left to see. Catch it in dev, while it's still visible, and the gate does its job.
Waivers as decisions, not shrugs
Not every finding is going to be fixed before tomorrow's promotion, and Flow Trace's rules and Fix list doesn't pretend otherwise — an anomaly moves from open to acknowledged to waived, and waiving one is allowed. What isn't allowed is waiving one silently. The interface won't let a waiver through without a typed reason, because "we decided to ship it anyway" without a reason attached isn't a decision. It's a shrug that happens to have a button next to it.
That reason doesn't just sit in the interface for the person who typed it. It's written into the hash-chained audit log, verbatim, alongside who made the call and when — which is a deliberately different treatment than, say, a support ticket, where the audit trail is built to record only that a ticket existed and changed status, never its contents. Waivers are the opposite on purpose: the entire point of a waiver is that the reason survives. Six months later, when a postmortem asks who decided an embedded secret was acceptable to ship and why, the answer isn't a Slack thread nobody can find or a memory nobody trusts. It's a chained, tamper-evident entry that says exactly what was decided, by whom, and when — and any attempt to edit that entry afterward breaks the chain visibly, which is its own answer to "are you sure that's really what was decided."
The gate
All of it resolves into one verdict: pass or fail, computed from whatever is still active. A single blocking anomaly — a control the CoE or Microsoft's own platform marked as a release-stopper — holds the promotion. Waive it, with a reason, and it moves out of the ledger for gate purposes, but the record of the waiver doesn't disappear; it just stops blocking. That's the whole design in one sentence: nothing ships unreviewed, and nothing that ships unreviewed on purpose does so without a name and a reason attached to it.
What changes for the CoE lead
The standards document doesn't go away — if anything it gets shorter, because every rule in it that's worth enforcing is now a control instead of a paragraph. What changes is that nobody has to remember to check it, because the check runs itself on every promotion, with citations that make each rule defensible in a room instead of a matter of opinion, and a waiver process that turns "we'll deal with it later" into a dated, accountable decision instead of an unwritten exception that surfaces only when something breaks.
See it yourself
The built-in rules are on the moment an environment connects, each one citing the Microsoft documentation it rests on, evaluated against your own flows on the next collection. You see your own estate's findings, and your own release verdict, before you decide whether this is how promotion should work.
Recognise this night? Score your own estate in three minutes, or talk it through with the person who wrote this.