Power Automate moves it. Helm proves it.

Audience: IT and automation teams already running Microsoft Power Automate Desktop
Status: pattern documented here; a first-party connector is a later phase, not yet shipped
Last reviewed: 2026-07-23

The question this answers

Most banks and enterprises evaluating Helm already run Microsoft Power Automate Desktop (PAD) for RPA. The natural question is whether Helm replaces it. It does not, and is not designed to: PAD is a mature, widely deployed tool for moving data and triggering actions across desktop applications. Helm's job starts where PAD's ends: proving, with cryptographic evidence, exactly what a computation did and that the record has not been altered since.

Division of labor

	Power Automate Desktop	Helm
Job	Moves data, clicks through UIs, triggers actions across desktop and cloud apps	Runs a deterministic kernel, journals every step, produces a signed evidence bundle
Output	Completed workflow run, application-level logs	Offline-verifiable evidence: inputs, outputs, kernel ID + hash, timestamp anchor
Auditor question it answers	"Did the flow run?"	"What exactly did it compute, and can a third party verify that independent of us?"
Replay	Not deterministic by design (UI automation, live app state)	Deterministic: the same inputs recompute the same output and hash, byte for byte

How they connect

The intended pattern keeps each tool doing what it already does well:

A PAD flow does its normal job: extracts data from a source application, prepares a file or payload the way it already does today.
At the point where the flow needs a governed, evidenced computation, it hands that payload to Helm, either by dropping a file into a watch-folder helmd monitors, or by calling helmd's local API directly (PAD's HTTP/desktop-flow actions can call a loopback endpoint like any other local service).
Helm runs the relevant kernel, journals the step, and returns a signed evidence bundle: the computed result plus the proof that it was computed correctly.
The PAD flow continues as it would normally, now carrying Helm's evidence bundle alongside its own output.

Helm never needs credentials to the applications PAD already automates, and PAD never needs to understand kernel logic, hashing, or evidence formats. Each system's failure mode stays contained: if a PAD flow breaks, Helm's evidence pipeline is unaffected, and a Helm evidence bundle remains independently verifiable (via the offline verifier embedded in every bundle) even if the PAD flow that invoked it is later retired.

This is a documented invocation pattern today, not a packaged PAD connector. Docs first, a first-party connector pattern is a candidate for a later phase and is not committed to a ship date. Nothing here requires Microsoft's cooperation or a marketplace listing to use: any PAD flow that can write a file or call a local HTTP endpoint can invoke helmd today.

Why this framing, not a competitive one

n8n's air-gapped/self-hosted mode ships execution logs, not signed, independently verifiable evidence, and has no deterministic-replay story. Zapier and Make have no air-gapped or on-premises story at all. Power Automate Desktop is the one already inside most banks' IT estate, with real deployment scale and support relationships. Positioning Helm as the evidence layer that sits alongside PAD, rather than a rip-and-replace RPA competitor, matches how these tools actually get adopted: incrementally, next to what already works.

Questions about a specific PAD integration scenario: [email protected].