If you’ve ever tried to push a genuinely large file into SharePoint from Power Platform, you’ve met the wall. The connector caps your payload, and the usual workaround — base64-encoding the bytes and passing them through a flow — makes it worse, because base64 inflates the payload by about a third before it even moves. On the files that matter most, the big ones, it falls over. Slowly, and then all at once.
For an enterprise client I stopped fighting the connector and moved the file transfer out of it entirely. This is the pattern that stuck.
Table of contents
Open Table of contents
The idea: the connector never touches the file
The trick is to stop treating the flow as the thing that carries the bytes. Instead, it carries a URL.
- A small Azure Function hands the client a short-lived upload URL.
- The client uploads the bytes directly to Azure Blob Storage — not through the connector, not through a flow.
- A second Function streams that blob straight into SharePoint.
The connector’s only job is to move a URL around. The file itself never passes through it, so the connector’s size limit stops being your problem. From a Canvas app, this comfortably moves files north of a gigabyte.
The two details that make it production-safe
The shape above is the easy 80%. The two details below are what separate a demo from something you can leave running.
No keys anywhere. The upload URL is a user-delegation SAS, minted with the Function’s managed identity rather than a storage account key. There’s no secret to leak or rotate — just a role assignment (Storage Blob Delegator) on the storage account. If your current large-file story involves an account key sitting in configuration somewhere, this is the part worth stealing.
Backdate the SAS start time. This is the one that costs an afternoon if you don’t know it. Clock skew between services means a SAS whose validity starts “now” will intermittently come back as not yet valid — a flaky, maddening failure that reproduces on no schedule. Backdate the start time by five minutes and the whole category of “sometimes the upload just fails” disappears.
When the file is genuinely huge
For files past a certain size, one shot isn’t enough, and the reassembly deserves its own note. Above the single-request threshold (around 10 MB in the code that stitches files into SharePoint), the upload switches to a chunked session, and the reassembly streams rather than buffers.
The naive version reads all the chunks into a MemoryStream and uploads that — which works right up until a file crosses roughly 2 GB, where a single MemoryStream hits .NET’s ceiling and you’re out of memory on precisely the uploads you can’t afford to fail. So there’s no full buffer anywhere: a producer streams each staged chunk through a System.IO.Pipelines pipe, and the SharePoint upload reads from the other end. Bytes flow through; they’re never all held at once. A multi-gigabyte file uses a small, flat amount of memory regardless of size.
The payoff
Once the file transfer lives outside the connector, the connector’s limits stop shaping your architecture. Large files land in SharePoint from a Canvas app, managed identity means there are no keys to manage, and the streaming reassembly means size stops being a memory problem. The connector goes back to doing what it’s good at — moving small, structured data — and the heavy lifting happens where it belongs.
If you’re still base64-ing files through a flow and hoping the big ones don’t show up, this is the exit. Hand out a SAS, upload to blob, stream to SharePoint, and let the connector carry a URL instead of a payload.
Slides: the condensed version is in a short deck — download the PDF.
How are you handling big-file uploads from Power Apps today — still base64, or have you moved off the connector?