What it does

Lets makers save a desktop flow as a reusable template — error handling, logging, a standard subflow structure — publish it, and have other makers create new flows from it. A flow created from a template is an independent copy, not a link.

Key facts

• Needs Power Automate for desktop v2.72 or later and a work or school account
• Created from the designer with File > Save as, choosing Template in the Type dropdown, either from a new automation or from an existing flow
• Saving an unsaved automation as a template creates only the template — nothing appears on the Flows page
• A template must be published before it shows up in the template picker; a draft is visible only under Templates to its owner
• Templates can't be run, scheduled or triggered from the console or from a cloud flow. You can run and debug them inside the designer while authoring
• Console has a Templates page with My templates and Shared with me tabs, showing status, tags and description, with search and filters
• Sharing is done from the portal: My flows > Desktop flow templates > Share. Co-owner permission allows editing, user permission is read-only
• Template and flow are fully independent in both directions — publishing a new template version doesn't touch flows already created from it, and deleting the template doesn't affect them

When to use / skip

Worth it where you have several makers building similar automations and want a common shape to error handling, logging and naming. It's the closest thing desktop flows have had to a starter kit. Skip it if you were hoping for shared components that update downstream — that isn't what this is, and treating it as one will bite you. For genuinely shared logic that must stay in sync, you still want a child flow or an external module, not a template.

Configuration decisions

• What belongs in the template: a structural skeleton (try/catch, logging subflow, connection variables) ages better than business logic, because nothing you put in propagates later
• Who owns templates: decide whether a CoE or RPA lead owns the published set, or makers publish freely. Without an owner you end up with fifteen near-identical templates and no canonical one
• Sharing model: co-owner for the small group allowed to evolve a template, user for everyone else. Handing out co-owner broadly makes the canonical template drift
• Naming and tagging: tags are the only real organisation the Templates page offers, so agree a scheme before there are thirty of them
• Versioning convention: since there's no version history surfaced, put the version in the name or description if it matters

Gotchas

• The copy is one-way and permanent. People will assume a template behaves like a solution component or a child flow and that fixing the template fixes the flows. It doesn't. Say this out loud in enablement, because the first time a bug is "fixed centrally" and nothing changes, trust goes.
• Draft templates are invisible in the picker, so a maker who has been told a template exists will report it missing. Check publish state before debugging permissions.
• You can't schedule or trigger a template, which catches people who built a template out of a working scheduled flow and expected it to keep running. Creating the template from an existing flow leaves that flow untouched — it's the template that's inert.
• v2.72 is a hard floor. In estates where the desktop client is deployed by SCCM or Intune and lags, makers will see the Templates page from colleagues' screenshots and not have it themselves.
• Template sharing lives in the portal, template authoring lives in the console. Two places, and the one people look in first is usually the wrong one.

Consultant notes

• Clients scoping "reusable automation components" will hear templates and think they've got what they asked for. They haven't — this is standardisation of new builds, not reuse of shared logic. Get that distinction settled in design, because the difference shows up as rework eighteen months later when a logging change has to be applied to forty flows by hand.
• The realistic value case is onboarding speed and consistency, not maintenance savings. Pitch it that way and it holds up; pitch it as DRY and it won't survive the first audit of duplicated logic.
• Governance question worth raising early: templates are per-environment, so a template published in Dev doesn't exist in Prod. If makers build in Prod — and in plenty of RPA estates they do — you'll need a story for how the canonical template gets into each environment.
• Haven't had this in a client tenant yet, so treat the permissions detail as documented rather than tested. In particular, confirm what a user-permission recipient can actually do with a template before you write it into a governance policy.

---

Worth revisiting once template versioning or solution-awareness appears, and after the next desktop client release.