[Bug]: Inline-only email attachments are skipped because `hasAttachments` is used as a fetch gate

[g-Bergsma]

Describe the issue

The Outlook/Graph email integration uses the message's hasAttachments property to decide whether to fetch attachments at all. However, hasAttachments only reflects regular attachments — it excludes inline attachments (e.g. images pasted into the email body). As a result, messages containing only inline attachments report hasAttachments: false, causing the attachment-fetch step to be skipped even though the attachments are genuinely present and retrievable via $expand=attachments. This means inline-only attachments are silently lost.

Expected behavior

Attachments should be retrieved for any message that actually has them, regardless of whether they're inline or regular. Specifically, I expected the attachment-fetch step to run unconditionally (not gated on hasAttachments), so that a message containing only an inline image would still have that attachment fetched via $expand=attachments — with any distinction between inline and regular attachments handled afterward, per-attachment, using isInline and contentId/cid: correlation, rather than being used upfront to decide whether to fetch at all.

Steps to reproduce

1. In Business Central, using a feature that processes inbound email via the Outlook/Graph integration (e.g. an AI agent such as the Sales Order Agent or Payables Agent), have an external sender send an email where the only attachment is an inline image — for example, a screenshot pasted directly into the body of the email, with no separate file attached.
2. Let Business Central pick up and process the incoming email through the normal inbound flow.
3. Observe that the email is processed as if it has no attachments — the inline image is not retrieved, stored, or surfaced anywhere in BC.
4. Enable diagnostic/trace logging (or debug) around the attachment-fetching logic in the Outlook API helper codeunit, and confirm that the hasAttachments value returned for this message is false, causing the codeunit to skip the attachment-fetch call.
5. As a control, send a second test email to the same BC inbound flow, this time with a regular (non-inline) file attachment alongside or instead of the inline image. Confirm that in this case hasAttachments is true and the attachment is fetched and processed correctly.
6. Comparing steps 3–5 confirms the defect is specific to messages containing only inline attachments: the codeunit's reliance on hasAttachments as a pre-fetch gate causes those attachments to be silently dropped, even though they are present and retrievable.

Additional context

No response

I will provide a fix for a bug

• I will provide a fix for a bug

[github-actions]

🤖 AI triage completed. Product group, please validate the triage report (Microsoft internal access only, use Ctrl+Click to open in new tab).

---

_{Was this triage helpful? React with 👍 or 👎 on this comment to provide feedback.}