Almanac

Consultant KB for Microsoft Power Automate end to end: cloud flows, desktop flows and RPA, connectors and integration, AI and agent flows, process and task mining, approvals and human-in-the-loop, ALM and solutions, governance and security, licensing and capacity, monitoring and troubleshooting, plus cross-cutting decision guides. Implementation notes, configuration decisions and the gotchas that bite on real projects. Populated by the daily author agent from the Power Automate release plans, docs repo and product blog, plus the author's own consultant notes.

feature-from-mining-to-automation.mdv1 · history
CurrentApplies to Process miningUpdated last monthSource Microsoft Learn

What it does

The bridge between analysis and delivery. Automation recommendations mark activities on the process map where Power Automate has connectors that match the applications involved, and +Automate activities hands you into the flow designer with those connectors pre-suggested. Everything after that is a normal automation project.

Key facts

  • Recommendations appear as blue icons on process map activities. Selecting +Automate activities above the map opens the Power Automate designer with connector recommendations for the activities in the process.
  • In task mining, the recommendation engine detects when recorded actions used an application with Power Automate actions available — Outlook and Excel among them — and can generate a draft flow containing the relevant actions.
  • The recommendation is based on application-to-connector matching. It doesn't assess volume, value or feasibility.
  • The same analytics that identify the candidate also give you the baseline: case counts, mean and median duration, rework percentage per activity. That baseline is what you measure against afterwards.
  • Refreshing the process on a schedule means the same metrics can be re-read after the automation ships, on the same definitions.

When to use / skip

Use the recommendations as a shortlist generator and nothing more. The activities worth automating are the ones where frequency, duration and rework all point the same way and the business will accept the change — and the tool only knows about the first three. Skip the "automate everything with a blue dot" approach entirely; it produces a portfolio of small flows nobody asked for and it's how automation programmes lose their sponsor.

Configuration decisions

  • How candidates are prioritised — volume times duration gives you the crude time saving, but rework rate often points at higher-value fixes.
  • Whether the answer for a given candidate is a cloud flow, a desktop flow, an agent flow, or a process change with no automation at all. Plenty of findings are fixed by removing a step, not automating it.
  • What baseline metrics are frozen before the change, and where they're recorded.
  • Whether the process refresh keeps running post-delivery so benefit can be measured on the same numbers.
  • Who owns the benefit claim — the automation team, the process owner, or finance. Agree it before the first flow ships.

Gotchas

  • Automating a step inside a broken process makes the broken process faster. Check the variant analysis before you build; if there are 300 variants, standardisation beats automation.
  • The connector recommendation says an application has connectors, not that the specific action in the process is automatable through them. Draft flows from recommendations need real design work.
  • Benefit measurement fails when the event log changes shape after automation — new activity names, new resources, a different case ID pattern. Plan for the log to shift and keep the mapping stable.
  • Time saved on a step doesn't become time saved overall if the constraint is somewhere else. Automating a non-bottleneck activity produces a good-looking number and no business change.
  • If the process refresh was a one-off load for the assessment, there's nothing to measure against later. That decision gets made at ingestion, months before anyone thinks about benefits.

Consultant notes

  • Insist on a written baseline before build starts. Retrospective baselines are always disputed and the automation always loses the argument.
  • Position mining output as a prioritised backlog with a business case per item, not as a list of things to build. The prioritisation is the consulting; the flows are the easy bit.
  • Warn the sponsor that the first honest recommendation from a mining exercise is frequently "fix the process, don't automate it". Clients who bought an automation programme need that framed carefully, and early.
  • Keep the refresh running. The ability to show the same chart six months later with a better number is worth more to the next phase's funding than the automation itself.

Revisit when agent flows change what's realistically automatable — the shortlist criteria shift with the capability

Was this accurate?