Copilot Studio Workflow calling Sharepoint Create File

(0) Share

Report

Posted on by PL-25081330-0

Hi all,

I'm calling the Sharepoint Create File action from the new Workflow.

My source of data is a base64 string. So, first I need to convert this into binary.

The create file is corrupt because apparently the binary data is written as a string.

I suspect the @{} prefix to retransform the binary data into a string.

Any help is welcome

Categories:

Autonomous agents

All responses (16)

Answers (1)

Sort by

Suggested answer

Ashlesha-MSFT Microsoft Employee on at

Like
a
(0)

Report
Copy link

Link copied!

Hi,

The SharePoint Create file action expects File Content in binary format.

The `@{...}` syntax performs string interpolation, so its result is always a string. For raw Base64 content, enter the following as a standalone expression in the expression editor:

```
base64ToBinary(items('Loop_Attachments')?['contentBytes'])

```

Do not add `@{...}` or quotation marks manually. The underlying workflow definition may correctly store it as:

```
@base64ToBinary(items('Loop_Attachments')?['contentBytes'])
```

If the source starts with a Data URI prefix, such as `data:application/pdf;base64,`, use:

```
dataUriToBinary(items('Loop_Attachments')?['contentBytes'])
```

If the preceding action already returns binary file content, pass that output directly without converting it again.

References:

https://learn.microsoft.com/en-us/connectors/sharepointonline/#create-file

https://learn.microsoft.com/en-us/azure/logic-apps/logic-apps-workflow-definition-language#expressions

https://learn.microsoft.com/en-us/azure/logic-apps/expression-functions-reference#base64tobinary

https://learn.microsoft.com/en-us/azure/logic-apps/logic-apps-content-type
PL-25081330-0 26 on at

Like
a
(0)

Report
Copy link

Link copied!

Hi,

Thanks for your answer.

The editor keeps adding the `@{...}`

I remove it manually, click in the workflow and select the Sharepoint Create File again and it is back.

So, I can't remove it.
Suggested answer

sannavajjala87 1,113 Super User 2026 Season 2 on at

Like
a
(0)

Report
Copy link

Link copied!

Hi,

It looks like you're very close. In Power Automate, SharePoint Create file expects the file content as binary, so base64ToBinary() is normally the correct approach.

A couple of things to check:

Make sure contentBytes contains only the raw Base64 content and not a data URI prefix such as data:application/pdf;base64,....
If the value is already being treated as binary earlier in the flow, avoid converting it again.
Try using the expression directly in the File content field rather than embedding it inside text or quotes.

For example:

base64ToBinary(items('Loop_Attachments')?['contentBytes'])

If the created file is still corrupted, add a Compose action before Create file and inspect the value of contentBytes. In many cases the issue is that the source data isn't pure Base64 or has been converted to a string somewhere earlier in the workflow.

If your source is coming from an Outlook attachment, you may also be able to pass the attachment content directly to Create file without any Base64 conversion at all.

Thanks & Regards,

Manoj Annavajjala

www.powerplatformengineer.com
PL-25081330-0 26 on at

Like
a
(0)

Report
Copy link

Link copied!

Hi,

Thanks for your answer.

Since I'm saving Outlook attachments to Sharepoint, I followed your advice and removed the base64ToBinary function call.

The File Content parameter look like this now :

@{items('Loop_Attachments')?['contentBytes']}

Unfortunately the file is still corrupted.

I'm unable to remove the `@{}`.

The designer keeps adding it.

I compared the original file with the one stored in Sharepoint and the one in Sharepoint was converted from binary to UTF-8 text.

I attached both files to the post.

Small text.docx
Small text corrup...
Suggested answer

chiaraalina 2,553 Super User 2026 Season 2 on at

Like
a
(0)

Report
Copy link

Link copied!
Hi @PL-25081330-0

This works for me:

For File content, I’m using the raw expression:

@items('Loop_Attachments')?['contentBytes']

and not:

@{items('Loop_Attachments')?['contentBytes']}

With @{...} it is handled as a string.

Can you compare my setup in the screenshot this with your setup and maybe share a screenshot or more details of your loop (Loop Attachments)?

Thanks!
PL-25081330-0 26 on at

Like
a
(0)

Report
Copy link

Link copied!

Hi @chiaraalina,

I can type that value into the textbox :

Then if I leave the action and click back, I see this :

Then if I click on button "Switch to expression mode" I see this :

The parameters remain

"parameters": {

"folderPath": "@{outputs('Create_new_folder')?['body/{FullPath}']}",

"name": "@{items('Loop_Attachments')?['name']}",

"body": "@{items('Loop_Attachments')?['contentBytes']}",

"dataset": ""

}

I really don't know what to do. This is blocking for me.
Sam_Fawzi 1,150 Super User 2026 Season 1 on at

Like
a
(0)

Report
Copy link

Link copied!
Hey @PL-25081330-0,

The @{} is the whole problem, and it is not a Get Attachment issue. Your contentBytes is already populated, so fetching the attachment again will not help. @{...} is string interpolation, so Create file receives a string where it expects binary, then coerces it as UTF-8. That is exactly the corruption you described when you compared the two files.

Three things to try, in order:

Enter the expression using the </> (code view) icon rather than the dynamic content picker. The picker is what re-adds @{} when you navigate away and back. In code view it should save as "@base64ToBinary(items('Loop_Attachments')?['contentBytes'])" with no braces.

Add a Compose before Create file, set to base64ToBinary(items('Loop_Attachments')?['contentBytes']), and reference the Compose output in File content. Compose output is loosely typed and often avoids the coercion.

Open the same flow at make.powerautomate.com instead of the Copilot Studio workflow designer. Agent flows are solution aware cloud flows, so it is the same object, and the classic designer writes the binary parameter correctly. @chiaraalina, are you authoring in the classic designer? That would explain why yours holds and his does not.

If you need to unblock today, skip the connector and use Send an HTTP request to SharePoint:
POST _api/web/GetFolderByServerRelativeUrl('<folder path>')/Files/add(url='<file name>',overwrite=true)
with base64ToBinary(items('Loop_Attachments')?['contentBytes']) as the body.
Worth also confirming the content is intact before it reaches Create file. Compose length(items('Loop_Attachments')?['contentBytes']) should come back at roughly 4/3 the original file size.
Suggested answer

chiaraalina 2,553 Super User 2026 Season 2 on at

Like
a
(1)

Report
Copy link

Link copied!

Hi @PL-25081330-0

Please share how your Loop Attachments is configured, especially which output you are using as the loop input?

Thanks!
PL-25081330-0 26 on at

Like
a
(1)

Report
Copy link

Link copied!

Hi @Sam_Fawzi

Thanks for your help

Even if I edit through </>, the {} get automatically added.
I type the correct string, click on save and I see {} appear.

The Compose action has the same issue.

I tried editing the workflow through make.powerautomate.com

When I click the edit button I get this error :

My last option is the Graph API. Let's hope I find my way in that.
Sam_Fawzi 1,150 Super User 2026 Season 1 on at

Like
a
(0)

Report
Copy link

Link copied!

Hey @PL-25081330-0 ,

The broken link is expected. Agent flows appear in My flows but cannot be opened in the classic designer, so make.powerautomate.com will not help here. That confirms the designer is the constraint, and since code view and Compose both get rewritten, I would stop fighting it.

Two ways forward.

Move the work out of the agent flow. Build this as a normal cloud flow in make.powerautomate.com, created from blank rather than from Copilot Studio, then call it from your agent as an action. The classic designer stores the parameter correctly as "@base64ToBinary(items('Loop_Attachments')?['contentBytes'])" with no braces, and the file lands intact. This is the fastest way to unblock and it is what I would ship.

Or patch the definition directly. Export the unmanaged solution containing the agent flow, open the workflow JSON in the extracted package, change "body": "@{items('Loop_Attachments')?['contentBytes']}" to "body": "@base64ToBinary(items('Loop_Attachments')?['contentBytes'])", then reimport. It works, but do not reopen that action in the designer afterwards or it will rewrite the value again. Treat it as a stopgap.

Worth raising this with Microsoft either way. File content on Create file is declared as binary, and the workflow designer emitting a string interpolated value into a binary parameter with no way to override it is a bug, not a configuration issue.