Agnius Bartninkas recently shared something that caught my attention: the Power Automate Desktop January 2026 update (version 2.64) "apparently has less changes than most previous releases," but the items that did ship are "among the most important lately. Some really big things in there!"

That framing is exactly right. Sometimes release notes look short because Microsoft didn’t do much. Other times they look short because a few foundational changes quietly remove long-standing friction. PAD 2.64 feels like the second category: it makes desktop automation more practical for everyday Microsoft 365 users, strengthens error handling, and improves the experience of building resilient RPA flows.

Below, I’m expanding on the four points Agnius highlighted—because each one has real implications for how teams design, govern, and scale Power Automate Desktop automations.

The headline change: standard cloud connectors without Premium

Agnius put it plainly: standard cloud connectors are now available in PAD with free work/school accounts—and he called it "absolutely huge." I agree. This change closes one of the most frustrating gaps between cloud flows and desktop flows.

For years, the story for many organizations has been inconsistent:

In cloud flows, if you already have Microsoft 365 licensing, using standard connectors like SharePoint, Outlook, OneDrive, and Teams can be straightforward.
In desktop flows, the moment you needed to reach into the cloud (for example, read a SharePoint list or send an email through Outlook connector), licensing and connector availability often pushed teams toward workarounds.

Agnius described the practical pain: without Premium, people resorted to "inefficient automations" like driving the Outlook Windows app UI to send emails or syncing SharePoint files locally with the OneDrive client (which he notes is "absolutely not reliable at all") just so PAD could manipulate files on disk.

That’s more than inconvenience—it changes the risk profile of your automations. UI automation is inherently brittle: window focus issues, version differences, pop-ups, multi-factor prompts, and timing problems all increase failure rates. File sync workarounds introduce data latency, sync conflicts, and unpredictable file availability.

What this unlocks for real-world desktop automation

With standard cloud connectors available, you can design desktop flows that behave more like well-architected integrations instead of clever screen-scraping scripts. Examples that become more viable:

Email-driven processing without UI automation: trigger a desktop flow from a cloud flow, then use standard Outlook actions to fetch details, send responses, or route summaries—without automating the Outlook client.
SharePoint-first document handling: list items, download a document, process it locally (OCR, desktop app steps, legacy ERP entry), then upload results back—without relying on OneDrive sync timing.
Cleaner separation of responsibilities: use cloud connectors for the communication and storage layer; use PAD for the “last mile” interactions with legacy desktop applications.

The governance caveat: Default environment tension

Agnius added an important nuance I don’t want to gloss over: while this is a big win for SMBs, he also said he doesn’t like relying on the Default environment and would "block PAD in Default completely" in many cases because it’s hard to govern.

That’s the trade-off many admins face: easier access tends to increase adoption, but adoption without guardrails can create sprawl. If you’re a CoE lead or platform admin, consider these practical controls:

Dedicated environments for desktop automation (separate dev/test/prod if you can).
DLP policies that clearly define which connectors can be used together.
Naming conventions and solution-aware development to keep flows maintainable.
Visibility: inventory desktop flows and their owners; monitor failure rates; establish a support process.

"This is now no longer the case" (re: Premium being required for cloud-related work in PAD) is the kind of sentence that changes adoption curves—but only if governance keeps pace.

“Throw custom error”: the missing building block for business exceptions

Agnius also highlighted a new Flow Control action: "Throw custom error". If you build anything beyond small personal automations, this matters more than it sounds.

In well-structured automation, not all failures are “unexpected.” Some are business rule outcomes:

A customer record doesn’t exist
An invoice total doesn’t reconcile
A file is missing a required column
A login succeeds but the user lacks a needed role

Without a proper way to raise named exceptions, builders often misuse generic failures (or “Stop flow”) and then try to infer what happened from logs or scattered conditions. A dedicated action for business exceptions helps you make intent explicit.

Agnius pointed out it works well with "On block error", even without enabling "Capture unexpected logic errors." That’s useful because it encourages a disciplined pattern:

Validate inputs and prerequisites
If a business rule fails, throw a clearly named custom error
Catch it in a scoped error handler
Decide: retry, skip, escalate, or route to a human

Consistent naming is a real productivity feature

One detail from Agnius that I love is the “Error name” dropdown surfacing existing errors after you create a few. That’s subtle, but it nudges teams toward consistent taxonomy. Consistent error naming improves:

reporting and analytics (group failures by type)
runbook documentation (clear mapping from error to resolution)
maintainability (future builders don’t invent “InvoiceMissing” vs “MissingInvoice” vs “NoInvoiceFound”)

Note on “Stop flow” behavior

Agnius mentioned this doesn’t fundamentally change how "Stop flow" behaves inside "On block error"—likely to avoid breaking existing flows. That’s a good reminder: use the new action intentionally. Think of it as “raising an exception with meaning,” not simply halting execution.

If you don’t see it: solution version matters

Agnius shared a practical troubleshooting point that will save people time: he didn’t see the new action until updating the Dataverse solution version to 1.9.35.0 (as indicated in the release notes) and restarting PAD.

This is a classic Power Platform reality: “I updated the app” doesn’t always mean “my environment has the required solution updates.” When features are delivered through solutions, your tenant and environment state can lag behind the desktop client version.

If your team is rolling out PAD 2.64 and someone reports missing actions, add a simple checklist to your internal rollout notes:

Verify PAD desktop version
Verify environment has the required solution version
Restart PAD after solution updates
Confirm the user is in the expected environment

Error handling UI redesign: quality of life that reduces mistakes

Agnius described the error handling screens redesign as a nice-to-have, but more intuitive. I’d argue these UI changes have an outsized impact because error handling is where small misunderstandings become production incidents.

Better screens typically lead to:

fewer flows silently ignoring errors
clearer choices between “continue,” “retry,” and “fail”
more consistent configurations across a team

This is especially relevant as PAD reaches more users (which the connector change will accelerate). When citizen developers build automations, the platform has to make “the safe way” the obvious way. A more intuitive error handling setup is part of that.

Environment variables: a feature tease (and what to do meanwhile)

Finally, Agnius addressed an awkward moment: the environment variables functionality he posted about previously "was apparently a mistake" and was pulled in the first hotfix after the release. It’s disappointing, but it’s also useful signal: it’s coming.

Environment variables are one of the most important building blocks for ALM and maintainable automation. They help you avoid hardcoding values like:

URLs
file paths
mailbox addresses

Until PAD environment variables are properly rolled out and supported, I recommend standardizing interim patterns:

Store configuration in Dataverse tables or SharePoint lists (depending on your governance model)
Use a single “Get configuration” subflow early in execution
Keep secrets out of plain text; rely on approved credential storage

The key is to treat configuration as data, not as flow logic. That mindset makes it easy to adopt environment variables later without a redesign.

What PAD 2.64 really signals

If I had to summarize Agnius’s post in one takeaway, it’s this: PAD is becoming more “platform” and less “desktop scripting.”

Standard cloud connectors reduce brittle UI and sync hacks
Custom errors elevate flows from “works on my machine” to predictable operations
Improved error handling UX reduces accidental fragility
Even the environment variables hiccup suggests Microsoft is pushing toward better ALM

If you build or govern automations, PAD 2.64 is worth more than a quick skim of the notes. It’s an opportunity to revisit patterns: replace workarounds with connectors, name your business exceptions, and tighten governance so adoption doesn’t turn into chaos.

This blog post expands on a viral LinkedIn post by Agnius Bartninkas, Operational Excellence and Automation Consultant | Power Platform Solution Architect | Microsoft Biz Apps MVP | Speaker | Author of PADFramework. View the original LinkedIn post →