Microsoft Outlook attachment downloads incomplete XLSX file (Graph returns different content than Outlook)

[Sneha-19195]

Describe the problem/error/question

I have a workflow that has been working correctly until June 29, 2026.

The workflow reads an email from Microsoft Outlook using the Microsoft Outlook Trigger, downloads an Excel attachment, extracts the rows, and processes the data.

Since June 29, the workflow downloads an incomplete Excel file.

The original attachment downloaded directly from Outlook contains employee data, but the attachment downloaded through the Microsoft Outlook nodes in n8n contains only the header row.

I reproduced the problem using multiple approaches.

Workflow tested:

Microsoft Outlook Trigger
↓
Extract From File

Then I also tested:

Microsoft Outlook Trigger
↓
Get Message
↓
Get Many Attachments
↓
Download Attachment

Both methods download the same incomplete XLSX file.

I also:

• Recreated the Outlook Trigger node
• Reconnected Outlook credentials
• Marked the email unread and fetched it again
• Created a completely new workflow

The issue still occurs.

---

Expected behavior

The downloaded attachment should be identical to the attachment downloaded directly from Outlook.

---

Actual behavior

The attachment downloaded by Outlook contains employee records.

The attachment downloaded by Microsoft Outlook Trigger / Download Attachment contains only the header row.

Outlook attachment size:
4195 bytes

Downloaded through Microsoft Graph (n8n):
3593 bytes

The downloaded file from n8n is missing all employee rows.

---

What is the error message

No error is returned.

The workflow executes successfully.

The problem is that the downloaded attachment content is different from the original Outlook attachment.

---

output returned by the last node

Get Many Attachments returns:

{
  "name": "Exit Report- Yesterday.xlsx",
  "size": 3959,
  "contentType": "application/xlsx"
}

Download Attachment downloads the same 3959-byte file.

However, downloading the attachment directly from Outlook produces a 4195-byte file containing the actual employee data.

Could you please verify whether this is a Microsoft Outlook node issue or a Microsoft Graph attachment retrieval issue?

This workflow worked correctly until June 29, 2026, without any workflow changes. The issue appears only for this attachment when retrieved through the Microsoft Outlook nodes.

Exit Report- Yesterday (8).xlsx
Exit Report- Yesterday (9).xlsx

[n8n-assistant]

Hey @Sneha-19195,

Thank you for reaching out! We’ve received your issue and are looking into it. To help us track this internally, we’ve created a Linear ticket with the reference: "GHC-8863".

We’ll keep you updated as we make progress, but if you have any additional details or context to share, feel free to add them here - it’s always helpful!

Thanks for your patience and for bringing this to our attention.

---

For INTERNAL use only: GHC-8863

[Sneha-19195]

Hi Team,

I would like to provide an update on this issue.

Today, the workflow was triggered automatically by the Cron node as scheduled. Initially, I thought the issue was resolved because the workflow executed successfully. However, when I manually triggered the workflow to verify the API response, the same issue still persisted. The downloaded Excel file contained only the header row and no employee data.

To verify this, I manually executed the same workflow, and the exact same issue occurred. The attachment downloaded through the Microsoft Outlook nodes still contains only the header row, while downloading the same attachment directly from Outlook contains all the employee records.

I have also verified the following:

• Recreated the Microsoft Outlook Trigger node.
• Reconnected the Outlook credentials.
• Created a new workflow for testing.
• Tested using Get Message → Get Many Attachments → Download Attachment.
• The attachment downloaded through n8n is always 3593 bytes.
• The same attachment downloaded directly from Outlook is 4195 bytes and contains the expected data.
• Other Outlook workflows in the same n8n instance are working correctly.

The issue appears to be isolated to this specific attachment when retrieved through the Microsoft Outlook integration.

Please let me know if you need any additional logs, workflow export, or sample files for further investigation.