Power Platform & Business Automation

Not every manual process is worth automating, and building the ones that are not is how automation programmes lose their sponsor. The discipline is in selection, and the selection criteria are more specific than volume.

The processes that repay automation share a shape: they run often, they follow rules that can be written down, they involve waiting on a human who is not adding judgement, and they re-key data that already exists in a system of record. Vendor onboarding, access requests, expense approval, new-starter provisioning, invoice matching, field data capture - the same categories recur across industries because the underlying shape is the same.

The measure that matters is cycle time, not effort. A process that consumes ten minutes of someone's attention but sits in an inbox for four days is costing you four days. Automating it does not save ten minutes; it removes four days from a chain that something else was waiting on. That is where the return is, and it is invisible if you only measure headcount effort.

Error rate is the second measure. Every point at which data is typed from one system into another is a place where errors originate, and the cost of a purchasing error is rarely the correction - it is the downstream reconciliation, the supplier relationship, and the audit finding. Removing re-keying removes a whole class of failure rather than reducing its frequency.

In almost every organisation running Power Platform without governance, there is an inventory nobody has: hundreds of apps and flows built by business users on individual accounts, some trivial, a handful genuinely load-bearing. Discovering this is usually uncomfortable, and it is worth being clear that it is not a failure of the people who built them.

They built them because a real business problem existed, IT had a backlog measured in quarters, and the platform made it possible. That is the intended outcome of low-code - the failure is architectural, not individual. What was missing was an environment strategy that gave them somewhere safe to build.

The risks are concrete. Flows running under a personal connection that stops when the account is disabled. Business data moving between services with no data loss prevention policy in the path. No source control, so there is no way to see what changed or to revert it. No test environment, so changes are made in production by definition. And no support model, so when it breaks the only person who understands it may no longer work there.

The remediation is not to ban it - that simply pushes it further out of sight. It is to inventory what exists, identify the genuinely business-critical subset, migrate those into managed environments with proper ownership and service accounts, and retire the rest on a communicated schedule. Then give people a governed place to keep building, because the demand that created the shadow estate has not gone away.

Environment strategy is the foundation and it is usually the thing that was skipped. At minimum you need separation between where people experiment, where things are tested, and where the business depends on them - with different rules and different permissions in each. Without that separation, every governance control has to be set to production strictness everywhere, which makes experimentation impossible and drives people back to shadow building.

Data loss prevention policies define which connectors can be used together. This matters more than it sounds: the risk in low-code is rarely a single connector, it is the combination - a connector reading from your CRM in the same flow as one writing to a personal cloud storage account. DLP policies are what stop that combination existing, and they need to be designed per environment rather than applied uniformly.

Application lifecycle management means solutions, source control, and a deployment path from development through test to production. Low-code does not exempt you from this. A flow that approves payments deserves the same change discipline as any other system that approves payments, and the platform supports it - it simply has to be set up.

Done well, this makes citizen development an asset. People build inside guardrails, the critical things are identified and supported, and IT spends its time on the hard integrations rather than policing. Done badly - or not at all - you get the shadow estate back, and the second cleanup is harder than the first because trust has been spent.

Conversational agents fit a narrow and genuinely valuable slot: high-volume, well-bounded questions where the answer exists in documentation or a system, and where the current cost is a person answering the same thing repeatedly. Internal IT and HR support are the obvious cases, and they work.

They fit badly where the question is open-ended, where the consequence of a confidently wrong answer is significant, or where the underlying information is inconsistent. An agent grounded on contradictory documentation will answer contradictorily and with complete confidence, which is worse than no agent because it carries institutional authority.

The governance requirements are the same as anything else touching business data, and are frequently underestimated because the interface looks casual. Access to grounding data must inherit from your identity model rather than being granted to the agent broadly. Conversations and outputs need logging. There must be a defined escalation path to a human, and it must be easy to reach rather than buried.

Our position is that this is worth doing where the bounded case exists and worth declining where it does not. The failure mode we see most is an agent deployed with enthusiasm across an ambiguous domain, producing enough wrong answers in the first fortnight that people stop using it - after which the effort to rebuild trust exceeds the effort of the original build.