Answered

Can't open PDF files sent by workflow within agent via outlook

(1) Share

Report

Posted on by Guy-JM

I was asked to create a power automate workflow to get users to submit pdf files for expenses claims. This then sends a structured email to a user with all the attachments. This works without issue.

For both learning and functionality enhancements, I then created a copilot agent to do the same thing.

I now have a workflow within the agent that is sending an email with the same PDF attachments as the original solution only these PDFs cannot be opened.

I get the message below.

The code in both copilot and power automate are identical so I can see no reason why they do not open when sent by copilot.

Power Automate:

Copilot:

I have checked the Contentbytes are the same and they do appear to be. Any thoughts why seemingly identical attachment structures are returning different results?

Categories:

Calling actions from Copilot Studio

General topics

I have the same question (0)

All responses (3)

Answers (0)

Sort by

Suggested answer

Haque 3,653 on at

Like
a
(2)

Report
Copy link

Link copied!

Hi @Guy-JM,

Just before opening up, can you download the attached PDF ? If file is downloadable locally (in your desktop), let's open the downloaded file using a dedicated PDF viewer like Adobe Acrobat Reader or your default web browser (e.g., Microsoft Edge or Google Chrome).

Let's troubleshoot the issue from different angle if not file is downloaded:

Step-1: Could you please narrow down the problem first? Let's send a simple emil with a hardcoded pdf attached in the agent flow. We will be able to narrow down if the issue is with attachment retrival or sending email. This will bring a 50% solution I guess.

Step-2: Can you please test a hardcoded base64 PDF attachment in the agent's flow - and see what happens.

Step-3: Let's compare the raw MIME email source sent by both flows to check differneces in attachment encoding, headers and metadata etc. Here is a way out. If we can find it - it will reavel a lots of things.

Conclusion: The error "We can't open this file. Something went wrong" means the file content wasn't sent correctly. It's probably from agent's side - doubt is there its probably delivering an empty template or a broken text string instead of the actual binary file data.

We have resolved case here. A community debate is here.

Also, If you built this agent and flow, the error might happen because the old System.Activity.Attachments schema is deprecated, and passing raw URLs into an agent's file property will corrupt the file. Here is clue to drill down it bit further.

Was this reply helpful? Yes No
Suggested answer

Sunil Kumar Pashikanti 2,318 Moderator on at

Like
a
(1)

Report
Copy link

Link copied!

Hi @Guy-JM,

This happens because Copilot Studio passes file content as a string, while Power Automate expects binary for email attachments.

So even though ContentBytes looks identical, Outlook ends up treating it as raw text instead of decoding it → corrupted PDF.

Quick Fix

Use one of these:

Option 1 (most reliable):
In your Outlook “Send email” action, switch to attachment array input and use:

{
"Name": "expense.pdf",
"ContentBytes": {
"$content-type": "application/pdf",
"$content": "@{triggerBody()?['ContentBytes']}"
}
}

Option 2:
If you are using the standard UI fields, convert the string explicitly:

base64ToBinary(triggerBody()?['ContentBytes'])

If it still fails (Copilot often sends Data URI) like this: "data:application/pdf;base64,JVBERi0xLjQK..."

Fix by stripping the prefix:
base64ToBinary(split(triggerBody()?['ContentBytes'], ',')[1])

In short

It’s not a data issue, it’s a string vs binary runtime issue. Converting the content before sending fixes it.

✅ If one of the responses here solved your issue, please mark it as Accepted so others facing the same problem can benefit as well.
👍 If this or any other reply here helped you, feel free to give it a Like. It helps others and is always appreciated.

Sunil Kumar Pashikanti, Moderator
Blog: https://sunilpashikanti.com/posts/

Was this reply helpful? Yes No
Guy-JM 4 on at

Like
a
(1)

Report
Copy link

Link copied!

Thanks Sunil, the base64 conversion has fixed the issue.

I guessed there was some variance in how the data was being handled but had no idea what.

Was this reply helpful? Yes No