Automation governance

What is automation governance?

Automation governance is the set of decision rights, responsibilities, and controls an organisation uses to choose, build, run, change, and retire its automations. The scope covers workflows, API integrations, RPA, low-code apps, document AI, and other process automation.

It is not a central ban on building things. Good governance gives teams a safe route, clear standards, and a known place to escalate, so people can move quickly without each new automation becoming a hidden risk. The regime should match the risk: a personal reminder flow does not need the controls that a bot changing supplier bank details does.

The automation portfolio and intake

A central inventory records each automation's purpose, its process owner, its technical owner, the data and systems it touches, its risk, and its status. Without that list, nobody can answer what would break if a connector changed or a login expired.

Intake reviews the problem before a build starts: is the process stable, are there better options, what are the benefits, the exceptions, and the dependencies. Sometimes an API change or a process change beats UI automation. Intake also stops two teams automating the same work twice, which is only worth reusing when ownership and service levels actually line up.

Risk classes

Classify automations by financial impact, personal data, external communication, autonomy, volume, how easily the work can be reversed, and any legal controls that apply.

Then tie each class to concrete requirements: review, testing, separation of duties, monitoring, approvals, and a stop control. Labels without consequences are theatre. The point of a class is that landing in it changes what you must do before the automation goes live.

Roles

The process owner decides the outcome and accepts the business risk. The automation owner runs the service and its roadmap. Platform and security teams guard the technical guardrails. Makers and developers build and test, operations watches runs and incidents, and control owners check separation of duties and the audit trail.

At low risk one person can hold several of these roles, but record the conflicts. The person who builds a critical financial automation should not be the only one who signs it into production.

Security and data policies

Apply least privilege to the maker, the runtime, and support, and separate identities per environment and risk boundary. Record data classification, purpose, retention, and logging, and remember that screenshots and run histories can hold sensitive data.

On the Microsoft Power Platform, data loss prevention policies put this into practice by classifying connectors as business, non-business, or blocked. A resource that uses a business connector cannot combine it with a non-business one, which stops data crossing a boundary you did not intend. The same idea extends to desktop flow modules, and policies can apply per environment or across the whole tenant, with the more restrictive policy winning. Review external AI services, connectors, and data transfers, because a low-code component does not change who is responsible for privacy.

Running, monitoring, and retirement

Define service levels, alerts, support hours, and incident routes, and measure success on the business outcome rather than the technical run status alone. Track backlog, exceptions, manual corrections, credential expiry, and changes in the systems an automation depends on.

Practise the emergency stop and the manual fallback. An automation that nobody can safely pause is not well governed. Review automations regularly for use, ownership, cost, and risk, since an unused flow with live credentials is still an attack surface. When you retire one, stop its triggers, drain its work queues, revoke its rights, keep data per your retention rules, and remove the dependencies.

The role of a Center of Excellence

A Center of Excellence can supply the standards, platform services, training, and portfolio view that individual teams cannot maintain alone, while domain teams keep the knowledge and responsibility for their own processes. Microsoft ships a CoE Starter Kit for exactly this on the Power Platform.

A federated model pairs central guardrails with local delivery, and it only works when the decision rights and the minimum controls are concrete. Do not measure the CoE by the number of makers or bots alone. Look at safe reuse, incidents, delivery time, and the value that actually landed. Automation governance is working when teams can change things responsibly and faster, and it is always clear who acts when an automation fails. This is where automation governance meets ordinary data governance: the same discipline, applied to processes instead of tables.