Forum Discussion
Copilot Studio Agent Unable to Retrieve Usable DOCX/XLSX Content from OneDrive (and SharePoint)
Hi everyone,
I'm building a Copilot Studio agent that needs to read and process Word (.docx) and Excel (.xlsx) files stored in OneDrive. The agent can successfully locate files and retrieve metadata, but it appears unable to retrieve Office files as usable binary content.
I tested the behaviour using the OneDrive Get file content action:
- A text file (test.txt) was returned correctly and matched the original file contents exactly.
- A Word file (Test.docx) was returned beginning with the ZIP signature PK and contained recognisable DOCX entries such as [Content_Types].xml and _rels/.rels.
- However, the returned payload also contained large numbers of Unicode replacement characters (�).
- The returned content appears to be a text string rather than binary data or base64 content.
Because Office files are ZIP-based binary formats, the returned payload cannot be reconstructed into a valid .docx or .xlsx file, preventing downstream libraries such as python-docx and openpyxl from opening the file. Is there any way to resolve this issue?
1 Reply
hi edfencer The behavior described here points more toward binary content handling than an issue with the DOCX/XLSX files themselves.
The fact that test.txt comes back correctly, while the DOCX response starts with PK but contains “?” replacement characters, is a strong indication that the binary file is being interpreted as text somewhere in the Copilot Studio/Power Automate flow. Once the binary data has been decoded as text, the original bytes can be lost, which would explain why python-docx or openpyxl cannot open the reconstructed file.
A few things are worth checking:
- Confirm the output type of the OneDrive Get file content action. It should remain binary rather than being converted to a string.
- Avoid passing the file content through variables, JSON parsing, string manipulation, or other steps that may implicitly convert binary data to text.
- If the content needs to be passed to Python or another service, send it as binary or base64, rather than copying the displayed text representation.
- Test the same approach with a small DOCX/XLSX file to rule out payload-size or connector limitations.
- Check whether the same behavior occurs when using SharePoint - Get file content instead of OneDrive. If both behave the same way, that would further suggest an issue with how the flow/action is exposing binary content rather than with OneDrive itself.
One important point: seeing PK at the beginning doesn't necessarily mean the binary content is intact. The “?”characters are a good indication that some bytes have already been incorrectly decoded as Unicode, and those original byte values generally cannot be recovered reliably from that string.
If the requirement is for the agent to understand the contents of DOCX/XLSX files, another approach may be preferable to passing the raw Office file to Python. For example, extract the document text or Excel data first and pass the structured content to the agent. If the actual requirement is to preserve and process the original file, however, the binary/base64 representation needs to be maintained end-to-end.
It would also be useful to check the exact output schema returned by Get file content and how that output is being passed to the next action. That should help identify exactly where the binary-to-text conversion is occurring.
