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-hosted-machines-and-hosted-rpa.mdv1 · history
CurrentApplies to Desktop flowsUpdated last monthSource Microsoft Learn

What it does

Microsoft provisions and runs the Windows machines for you. A hosted machine is a single cloud PC you can sign in to and use for building, testing and running attended or unattended flows. A hosted machine group is a pool of unattended bots that Power Automate creates on demand, scales against your queue, and load balances across groups in the environment.

Key facts

  • Both need the Power Automate Hosted Process licence (previously the hosted RPA add-on). It licences the machine, not the user — makers still need Power Automate Premium to build and manage, and hosted machines have prerequisite Windows, Intune and Microsoft Entra ID licences behind them.
  • Hosted machines use Windows 365 for provisioning and access; hosted machine groups are provisioned by the Power Automate Hosted Machine Groups service principal.
  • Images: a Microsoft-supplied default based on the Windows 365 Cloud PC template for Windows 11 Enterprise 24H2 with Edge preinstalled, or your own generalised, Generation 2, trusted-launch-enabled image from an Azure Compute Gallery. The custom image ceiling for hosted machine groups is 127 GB.
  • Networking: the Microsoft hosted network by default, or your own Azure virtual network with a delegated subnet (Microsoft.PowerAutomate/hostedRpa). Up to 30 custom virtual networks per tenant. Microsoft Entra hybrid join over a custom VNet is in preview as of the January 2026 documentation.
  • Scaling is controlled by max bots (scale to this when work and capacity allow) and committed bots (guaranteed capacity). Total bots across the environment can't exceed the assigned Hosted Process capacity minus any hosted machines already provisioned.
  • Limits for hosted machine groups: 10 groups per environment, 50 bots per group. Groups without committed bots are deleted automatically after 28 days of no runs.
  • Hosted machine groups are unattended-only, direct-connectivity-only, and don't work with the cloud flow Test experience. You can't RDP into them.
  • Cold start is real: if a group is new or idle for more than three hours, provisioning a bot can take over 10 minutes before anything leaves the queue. A hosted machine can take over 30 minutes to become ready.
  • Hosted machine groups run in GCC, GCC High and DoD with feature gaps (no work or school account in any of the three; no custom images in GCC or DoD) and aren't available in China. Hosted machines aren't in sovereign clouds at all.

When to use / skip

This wins whenever the client has no appetite for building and patching a VM estate, or when demand is spiky and paying for idle servers is the bigger cost. It also wins for speed — you can be running unattended within an afternoon rather than after a two-week infrastructure ticket. Stay self-hosted when the automation needs software or hardware you can't put in an image, when the target systems are locked to on-premises network paths that a custom VNet won't reach cleanly, or when the client's security posture won't allow Microsoft-managed machines touching production apps.

Configuration decisions

  • Hosted machine or hosted machine group: sign-in access and attended support, versus autoscaling unattended throughput.
  • Default image or custom image, which really means whether your line-of-business apps can be installed at all.
  • Microsoft hosted network or your own VNet, and if your own, whether Entra join or hybrid join is required for the apps being automated.
  • The max-bots and committed-bots split per group, which is how you decide which process gets starved when everything runs at once.
  • Work or school account versus a local admin account for the bots, since the former gives the bots access to Microsoft 365 and Azure resources under the organisation's plan.

Gotchas

  • The queue looks stuck for ten-plus minutes on a cold group. People cancel the run and file a bug. Set expectations, or keep committed bots for anything time-critical.
  • Groups with no committed bots that go quiet for 28 days are deleted, and you have to recreate the group and reconfigure the connection. The dead group stays visible, which is confusing.
  • The default image on hosted machines needs Network Level Authentication disabled for unattended runs — a step that's easy to miss and produces an unhelpful logon error.
  • Custom images must be replicated into the specific Azure region mapped to your environment's geography, not just "somewhere in Europe".
  • Hosted Process capacity is consumed by hosted machines as well as bots, so a couple of hosted build machines quietly reduce the unattended ceiling.

Consultant notes

  • Frame Hosted Process as buying capacity, not machines. That reframing makes the max/committed bot conversation with the client much easier.
  • Custom images are where the effort actually lands. Budget real time for building, generalising and maintaining the image, plus the Azure Compute Gallery permissions dance with the service principal.
  • If the client is on GCC or DoD, check the feature table before designing — losing work or school accounts changes the credential story completely.
  • Keep at least one self-hosted machine in the design for anything that needs peripherals, elevation, or genuinely local network access.

Revisit when Entra hybrid join for hosted machine groups leaves preview, or when the client's image estate changes

Was this accurate?