Workflow Automation: 7 Smart Places to Start in Microsoft 365

Ever wished the form on your website just… created the job? That the invoice arriving in one inbox turned up in your accounting system without anyone retyping it? That when a deal closed in one place, the folder, the channel and the calendar invite appeared in another? That wish is the whole of workflow automation, and the honest answer for most small businesses is that you already own the tools to grant a fair bit of it.

What follows is not a sales pitch for a platform. It is the practical shape of workflow automation: what it actually is underneath, what you already have, what it costs when you outgrow that, and the counter running in the background that almost nobody knows about until it bites.

What workflow automation actually is

Strip away the branding and every workflow automation platform is the same two-part sentence. When this happens, do that. A trigger, then one or more actions.

The trigger is an event some system already knows about: a file lands in a folder, a form is submitted, an email arrives with an attachment, a row is added to a list, a date arrives. The actions are things another system can already do if asked politely: create a record, send a message, move a file, start an approval, write a row.

What connects them is an API — an agreed way for one program to ask another to do something, without a person in the middle. The reason this feels newly possible is not that APIs are new. It is that the big platforms now ship pre-built connectors for the common ones, so wiring two systems together is increasingly a matter of choosing from a list rather than writing code.

Webhook vs API: what is the difference?

These get used interchangeably and they are not the same thing. The distinction is direction, and it decides how quickly your workflow automation reacts.

An API is something you call. Your automation asks: any new orders? Any new files? Ask too rarely and you are slow; ask constantly and you burn your request allowance on questions whose answer is usually “no”.

A webhook is something that calls you. You register an interest once, and the other system contacts you when something actually happens. Microsoft’s change notifications documentation describes exactly this trade: an event-driven model “where customers receive alerts when changes occur instead of them polling”, and it lists avoiding throttling limits as one of the reasons to prefer it.

Two honest caveats, both from the same page. Subscriptions expire and have to be renewed — a mailbox subscription lasts under seven days, a presence subscription an hour — so a webhook is a thing you maintain, not a thing you set up once. And “near real-time” has a tail: Microsoft publishes an average delivery latency under a minute for OneDrive and SharePoint items, with a maximum of six hours. If your process genuinely cannot tolerate that, build it to check rather than to wait.

Do I already have workflow automation?

If you have Microsoft 365, almost certainly yes. Power Automate is included with Microsoft 365 licences, and Microsoft’s licensing overview is specific about what that gets you: you can build and run flows, connect to Microsoft 365 data, and “connect to cloud services using standard connectors”.

Standard connectors are not a token gesture. They cover SharePoint, Outlook, Teams, OneDrive, Excel, Forms, Planner and a long list of non-Microsoft services besides. A great many of the automations people actually wish for live entirely inside that set, which means the honest first answer to “what will this cost?” is often nothing beyond the licence you are already paying for.

Before you buy anything, log in and look. An unlicensed user who signs in to the Power Automate site gets a Power Automate Free licence, and trials run 90 days.

Why does it say I need a premium licence?

Because you have reached for something outside the standard set. The same licensing page marks the boundary in one line: the Microsoft 365 plan does not include “access on-premises data or use premium or custom connectors”.

Three things sit on the far side of that line, and between them they explain almost every premium prompt anyone runs into:

• Premium connectors — typically the business systems rather than the productivity ones. If you are connecting to a CRM, an ERP, a database or a paid third-party platform, expect to be on this side.
• Custom connectors — anything you wire up yourself against an API that has no ready-made connector.
• On-premises data — a server in your building, a SQL database in a comms room, a line-of-business application that never moved to the cloud.

None of that makes premium a rip-off, and plenty of useful workflow automation never crosses the line at all. It makes it a decision with a threshold, and the threshold is worth finding deliberately: build the free ones first, see what they are worth, and let the demand for a premium connector be the thing that justifies the licence rather than the other way round.

How many automations can I run?

Here is the part of workflow automation that rarely comes up until something stops working. Every Power Platform licence carries a request allowance, and Microsoft publishes the table. On an Office 365 licence the official limit is 6,000 Power Platform requests per user per 24 hours. Power Automate Premium raises that to 40,000 per user. There is also a five-minute ceiling of 100,000 requests that applies regardless of licence.

Two details matter more than the number. The allowance does not accumulate — “if you don't consume them, they don't roll over to the next day and they don't accumulate within a month”. And the 24 hours is a sliding window, so the question is always what you have spent in the last day, not since midnight.

Everyone is currently in what Microsoft calls a transition period, during which the enforced limits are more generous than the official ones and enforcement is not strict. That is a reason to design against the official numbers rather than the temporary ones. Building to a limit that is scheduled to tighten is how a working automation becomes a support ticket on a date nobody wrote down.

The counter counts more than you would guess

This is the single most useful thing in the documentation, and it is the reason estimates go wrong. A request is not one automation run. Microsoft counts “all API requests to connectors, process advisor analysis, HTTP actions, and built-in actions from initializing variables to a simple compose action”.

Read that again slowly. Setting a variable counts. A compose step counts. And then: “both successful and failed actions count toward these limits. Retries and requests from pagination also count as action executions”.

So a flow with a dozen small steps is a dozen requests every time it runs, a flow that fails still spends the allowance, a flow that retries spends it again, and a flow that pages through a long list spends one per page. A tidy-looking automation that runs on every incoming email in a busy mailbox can consume a six-thousand-request day considerably faster than the phrase “6,000 runs” would suggest — because it was never 6,000 runs.

One tempting escape route is closed off explicitly. Asked whether a non-Microsoft integration tool avoids the limits, Microsoft answers: “No. Non-Microsoft data integration tools are subject to the exact same limits.”

Whose allowance does it actually spend?

A quietly important question when an automation is shared. Instant flows, the ones a person starts on demand, use the limits of the account that starts them. Automated and scheduled flows “always use the limits of the owner of the process, regardless of why the process started or which accounts are used for connections”.

Which means a background automation built by one enthusiastic person and used by forty quietly spends that one person’s allowance. When it throttles, it throttles for everyone, and the symptom appears on the builder’s account rather than where the work is happening. Automations that matter should be owned by an account chosen on purpose, not by whoever happened to build the thing.

Seven smart places to start

Ordered by how quickly they repay the effort. Every one is workflow automation you can build on a standard connector, and all of them are the boring kind. That is deliberate — the automations that last are the ones removing a task nobody enjoyed and nobody will miss.

• Form to somewhere real. A submission becomes a row, a task and a notification, instead of an email somebody reads on Monday.
• File filing. Attachments landing in a named folder by sender, date or subject, so the search later actually finds them.
• Approvals. A request routed to the right person with a record of the answer, rather than a thread nobody can locate afterwards.
• New-starter setup. One trigger creating the accounts, the group memberships and the checklist — the joiner half of joiner-mover-leaver.
• The Monday report. Anything a person currently assembles by copying between two places on a schedule.
• Deadline nudges. Contract renewals, certificate expiries, licence true-ups — the things that only hurt when missed.
• Escalation on silence. If nothing happened within a defined window, tell someone. Most processes fail quietly rather than loudly.

The pattern in that list is worth naming, because it is what good workflow automation has in common. None of them are clever. Each replaces a handoff where information waits for a human to move it, and the waiting was always the expensive part.

What not to automate

Three categories where workflow automation makes things worse, learned the expensive way by people other than you.

A process nobody has written down. Automating a workflow that exists only in one person’s habits does not document it, it entrenches it in a form that is harder to read and harder to change.

Anything where being wrong is expensive and silent. Payments, permissions, deletions. Automate the preparation and leave a human on the button, at least until the thing has run visibly for a while.

A process about to change. If the system is being replaced in six months, the automation is six months of work you will throw away, and it will make the migration harder in the meantime.

Where workflow automation stops being free

Workflow automation is rarely free forever. Cost arrives in three places, in this order. First a premium or custom connector, when the systems you need are business applications rather than productivity ones. Then request volume, when the flows are numerous or chatty enough to press the daily allowance. Then ownership, when what began as one person’s helpful side project becomes something the business depends on and needs a proper owner, a service account and someone who notices when it stops.

That third one is not a licensing problem, and it is the one that actually catches people. An automation nobody owns is indistinguishable from a working process right up until the day it fails, and the failures are quiet by design — the same argument we made about the controls that fail without raising an error.

If you want the first few built properly and handed over rather than left as somebody’s hobby, that is what our automation and systems hardening work is for. And if the answer turns out to be that two systems genuinely cannot talk without a custom integration, that is an architecture conversation before it is a licensing one.