Create a File Hash in Power Automate: Three Honest Routes

Power Automate cloud flows do not have a general built-in action called Create SHA-256 hash.

That does not mean you need a large custom solution. It means you must first decide what the hash is for, because Microsoft 365 exposes different values for different jobs.

Your actual need	Best place to start
Detect whether a OneDrive or SharePoint file changed	Microsoft Graph's file-hash metadata, if the required hash is available
Produce a cryptographic SHA-256 hash in an attended desktop process	Power Automate for desktop plus PowerShell Get-FileHash
Produce SHA-256 in a cloud flow	A secured Azure Function/API or a governed third-party connector

There is no credible free-and-unlimited answer. Each route has a boundary around algorithm, file size, licensing, security or where the file is processed.

First: name the requirement precisely

Ask these questions before building anything:

1. Do you need to detect a changed file, find likely duplicates or verify a published checksum?
2. Is the required algorithm specifically SHA-256?
3. Where is the file: OneDrive, SharePoint, local disk or another system?
4. What is the largest file you must handle?
5. May the file content leave Microsoft 365 or your tenant boundary?
6. Is an attended desktop run acceptable, or must it run unattended in the cloud?

A hash is not encryption. It does not hide a file or make access safe. It is a deterministic value derived from the content. The same algorithm applied to the same bytes should produce the same result.

Route 1: use Microsoft Graph file hashes when change detection is enough

A Microsoft Graph driveItem can expose a file.hashes resource for files in OneDrive and SharePoint document libraries.

The important word is can.

Microsoft currently documents these properties:

• crc32Hash, when available;
• quickXorHash, when available;
• sha1Hash, when available;
• sha256Hash, which Microsoft explicitly marks unsupported and says not to use.

QuickXorHash is Microsoft's proprietary file hash for change detection. Microsoft guarantees it for OneDrive for work or school and OneDrive home, but that does not make it a cryptographic SHA-256 checksum. Read the current Graph hash resource.

When this route is appropriate

Use Graph metadata when:

• the file already lives in a Microsoft drive;
• a returned hash type satisfies your comparison requirement;
• your design can handle a missing hash;
• you are comparing values created by the same documented scheme.

Do not use it when a downstream system or audit procedure requires SHA-256. Do not silently substitute QuickXorHash just because it is present.

Cloud-flow outline

1. Trigger on a new or changed file.
2. Identify the drive and item.
3. Use an approved Microsoft Graph connection to retrieve the drive item with its file facet.
4. Check whether the required hash property exists.
5. Store the algorithm name and value together.
6. Route missing or unsupported values to an exception path.

Store this:

{
  "algorithm": "quickXorHash",
  "value": "<returned value>",
  "driveItemId": "<item id>",
  "observedAt": "<UTC time>"
}

Never store a bare value without recording the algorithm. Two hashes are comparable only when their algorithms and content boundaries match.

Route 2: use PowerShell from Power Automate for desktop

If the file is available to a Windows machine and an attended desktop process fits your operating model, PowerShell has a standard cmdlet for the job:

(Get-FileHash -LiteralPath $FilePath -Algorithm SHA256).Hash

Microsoft documents Get-FileHash as a cryptographic file-hash cmdlet and says SHA-256 is its default algorithm. -LiteralPath is useful when filenames contain wildcard characters. See the official Get-FileHash reference.

Desktop-flow pattern

1. Make the file available locally. If it begins in SharePoint or OneDrive, use a governed download/sync step and a unique temporary path.
2. In Power Automate for desktop, use Run PowerShell script.
3. Pass the local path as a variable rather than concatenating untrusted text into a command.
4. Return only the .Hash value.
5. Validate it with this SHA-256 shape before storing it:

^[A-Fa-f0-9]{64}$

6. Record the algorithm, source file identifier, size and modification time.
7. Remove the temporary local file according to your retention and error-handling policy.

Microsoft's scripting-actions reference documents PowerShell execution in desktop flows. Check the current Power Automate for desktop scripting actions.

Licensing boundary

Do not describe this route simply as “free.” Local desktop authoring, organisational management, cloud triggering, attended execution and unattended execution are different entitlements. Microsoft lists automatic cloud triggering, premium/custom connectors, sharing and central management among Premium RPA features. Unattended runs require the appropriate Process capacity and an available machine/session. Review Premium RPA features and unattended-run requirements.

Route 3: call a secured hashing API from a cloud flow

Use an Azure Function or another approved API when:

• the process must remain cloud based;
• SHA-256 is mandatory;
• Graph does not return a suitable hash;
• file sizes and volumes fit a deliberately designed service.

The API contract can be small:

POST /hash
Content-Type: application/octet-stream

<file bytes>

{
  "algorithm": "SHA256",
  "hash": "<64 hexadecimal characters>"
}

But the production design is not “paste a Function key into a URL.” Microsoft's Azure Functions guidance recommends positive authentication, least privilege, HTTPS, managed identities where possible, Key Vault for secrets, input validation and careful logging. Read Azure Functions security guidance.

Minimum production controls

• authenticate with Microsoft Entra ID or another approved identity layer;
• restrict callers and permissions;
• enforce maximum body size and timeouts;
• avoid logging file content or secrets;
• return a clear error for empty or partial content;
• define retry behaviour and an idempotency key where the caller may resubmit;
• use secure inputs/outputs for sensitive flow actions, remembering that run-history hiding does not authenticate the API;
• decide whether bytes may be processed outside the source service and region.

Microsoft's Power Automate guidance explains how secure inputs and outputs limit data shown in run history.

For large files, avoid assuming the connector can move the entire payload comfortably. Test the largest real file through the exact trigger, connector and API path. A streaming or storage-reference design may be better than placing every byte in a flow action.

What about third-party connectors?

A connector can be the fastest supported route if it already exists in your environment. Evaluate it as a supplier dependency, not a magic action.

Check:

• supported algorithms;
• maximum file and request sizes;
• connector classification and Power Automate licensing;
• where content is processed and retained;
• authentication and data-processing terms;
• throttling and retry behaviour;
• what happens if the connector is removed or the plan changes.

Do not copy a vendor price into a technical tutorial and treat it as permanent. Link to the current supplier page and record the commercial decision in your solution documentation.

A duplicate-detection design that does not overpromise

Hashes reduce expensive byte-by-byte comparisons, but they are not your entire records policy.

For every file, store:

• source service and immutable item ID;
• algorithm and hash value;
• file size;
• modification marker such as eTag/cTag where appropriate;
• observation time;
• the flow or service version that produced the record.

Then compare within the same algorithm. For high-consequence deletion, quarantine the candidate and perform an additional content or business check before removing anything.

Filename, Modified time and file size alone do not prove identical content. A matching non-cryptographic change hash may be adequate for sync optimisation but not for security evidence.

Test the route before production

Use a test set containing:

1. two byte-identical files with different names;
2. two files with the same name but different content;
3. an empty file;
4. a filename containing spaces, brackets and wildcard characters;
5. the largest supported real-world file;
6. a permission failure;
7. a timeout followed by a retry.

The identical files should produce the same value with the same algorithm. A one-byte change should produce a different cryptographic hash. A failed request must not be recorded as a valid empty hash.

Frequently asked questions

Is there a native SHA-256 action in Power Automate cloud flows?

Microsoft does not document a general native cloud-flow action that hashes arbitrary file content with SHA-256. Use a suitable Graph hash, desktop PowerShell, a secured API or a governed connector.

Can I use Microsoft Graph's sha256Hash property?

No. Microsoft's current Graph documentation marks sha256Hash unsupported and says not to use it.

Is QuickXorHash the same as SHA-256?

No. QuickXorHash is Microsoft's proprietary file hash for change detection. It is not a cryptographic SHA-256 checksum.

Can I run Get-FileHash directly inside a cloud flow?

Not as a general native cloud action. You can run PowerShell in Power Automate for desktop, or expose a governed cloud API that calculates the hash.

Does a matching hash make automatic deletion safe?

Not by itself. Match the algorithm, retain source identity and metadata, handle missing values, and use quarantine or a second check before consequential deletion.

For more production-safe Power Automate patterns, join the Power Automate Mastery Space.