Microsoft 365 · Robotic process automation

Business process automation for the work that repeats.

Approvals chased by email. Form responses re-typed into a list. The same attachments filed into the same folder, every week, by someone who has better things to do. All of it can run itself: through APIs where they exist, and through the screen where they do not.

Describe the task See the solutions catalogue

Whichever route your process takes, the automation is yours outright: documented, editable by your own people, and with no licence to keep renewing and nobody to keep paying.

Which of the two your process needs

It starts with the process, not the tool: what happens today, step by step, and which software each step touches. Two things about that decide which half the work belongs to, and they cost differently to build and to keep.

Is the software already Microsoft?

Yes: connector work
Then it can be reached through a published connector, and the automation joins the systems directly: cloud-to-cloud, with their data kept in step. This is the half the industry calls Digital Process Automation.

Not all of it
Then it depends on the next question. Plenty of non-Microsoft software publishes a connector too: Salesforce, Dropbox, hundreds of others. What matters is whether the software can be reached at all, not whose logo is on it.
Does any step happen on a desktop?

No: it is all system to system
Everything runs in the cloud. The automation talks to each system through its connector, needs no machine left switched on, and keeps running whether or not anyone is at a computer.

Yes: driven the way a person drives it
Mouse clicks, keystrokes and UI elements. A browser to click through, a workbook to manipulate, an application window to type into: legacy software and local files that publish nothing. This is Robotic Process Automation, or RPA, and it needs a machine to run on because no connector reaches it.

Answers on the left are connector work: Power Automate cloud flows. Answers on the right are RPA: Python. Neither is better; they are different jobs, and which one you have is a fact about your software rather than a preference. Many processes need some of each.

The difference is what each costs to keep, not which is better. Connector work needs no machine and survives screen changes; RPA needs somewhere to run and needs attention whenever a screen moves. Which one a process needs is a fact about that software, not a preference. It is also what decides the running cost, so it is worth settling before anyone quotes for it. Describe your process and you will be told which of the two it is.

Two halves, built differently

Which one your process needs is the first question, and it changes what the work costs to build, to licence and to keep, and how a project starts. Both are built from the same framework of proven, already-deployed pieces, and both are independently reviewed before anything goes live. What the design step is for differs; each page sets out how its projects run.

Microsoft Power Automate

Cloud flows through published connectors: Outlook, SharePoint, Teams, OneDrive, Forms, Excel, Planner and several hundred more. Nothing watches a screen, so nothing breaks when a screen changes. Included with most Microsoft 365 subscriptions.

Consultancy, development and support, the licence answer, how a project runs, and eighteen automations already built.

Power Automate →

Python RPA

Legacy line-of-business software, ERP screens and supplier portals that were never meant to be integrated with anything, driven the way a person drives them. Written as code rather than built in a low-code tool, so a complex process is not limited by what the tool allows, and there is no per-bot licence to pay.

When you actually need it, why Python rather than Power Automate Desktop, how a project runs, and what it costs to own.

Python RPA →

Common questions

The questions that come up before every project, answered properly rather than deflected to a call. The ones specific to each half are answered on their own page.

Does our data go to an AI?

Two different things. The automation itself does not. Once built it runs on systems you own (your Microsoft 365 tenant for cloud flows, your own machine for the Python half), and the records it touches stay there.

The design step is different, and it would be dishonest to blur them: what you send then is processed by a model. A written description is easy to keep clean: it needs the process, not the data, and "invoices arrive from suppliers and get filed by reference" is enough. A screen recording is not, because the screen shows whatever is on it, so record against a test or dummy case where you can. If either is a problem (some regulated environments rule it out), say so in the first conversation and it is handled without them.

What happens after the work is handed over?

The automation lives where it runs (your own Microsoft 365 tenant for cloud flows, a machine you own for the Python half), under your ownership and editable by your own people. Nothing about it depends on its author remaining involved. That is deliberate: an automation that only its author can change is a problem waiting to happen.

What if the process should not be automated?

Then that is what gets said, before any building starts. Automating a broken process only makes it fail faster, and more expensively. Finding that out is worth more than the project you did not buy.

What is the difference between cloud flows and Python automation?

A cloud flow talks to systems through their APIs and runs in Microsoft's cloud, needing no machine left switched on. Python is for everything the connectors cannot reach: it drives the screen on software that was never built to connect to anything. Use cloud flows wherever the API exists, and Python only where it does not.

Can you tell us which half our process needs?

That is the first question in any project, and it is answered before anything is built. Both halves are built here, so the recommendation is not shaped by what is on offer.

Describe the process that is eating the week

What comes back is an honest read: whether the process is worth automating at all, whether that automation belongs in Power Automate or somewhere else, and what it would take. No obligation attached to asking.