What is the supported OnMessageSend pattern when updating and sending an Outlook draft through Microsoft Graph in New Outlook for Windows?

We are evaluating an Outlook Web Add-in using the Smart Alerts OnMessageSend event in New Outlook for Windows, together with Microsoft Graph operations on the current draft.

We are trying to understand the officially supported way to coordinate the Outlook send event with Microsoft Graph operations.

During our POC, we observed the following behaviors.

1. Graph send with allowEvent: false

After the Graph operation completes, we call:

event.completed({

This prevents Outlook from continuing its native send flow.

However, Outlook displays a Smart Alerts dialog because the original send operation has been blocked.

Question

Is there a supported way to stop Outlook's native send without showing a user-facing dialog when the message has already been successfully handled through Microsoft Graph?

---

2. Closing the compose item

If we do not complete the event immediately and instead try to close the compose item:

Office.context.mailbox.item.close();

Outlook displays an unsaved-changes confirmation.

We also tested:

Office.context.mailbox.item.closeAsync({

This closes the compose window silently in our testing.

However, the closeAsync documentation states that it is not supported in event-based handlers.

Questions

• Why does closeAsync({ discardItem: true }) currently work inside OnMessageSend in New Outlook for Windows?
• Can this behavior be relied upon?
• What is the officially supported alternative for closing or dismissing the compose item from an event-based handler?

---

3. Graph send with allowEvent: true

We also tested:

event.completed({

Since the message had already been handled through Graph, we expected Outlook's native send to potentially produce a duplicate message.

However, in our testing, only one message was delivered.

Questions

• What is the defined behavior when the current draft has already been sent or changed through Graph and allowEvent: true is subsequently returned?
• Does Outlook detect that the underlying draft has already been sent or changed?
• Is the absence of a duplicate message guaranteed, or is this undefined behavior that should not be relied upon?

---

4. HTTP 412 / ErrorIrresolvableConflict

We also update an active draft through Microsoft Graph using:

PATCH /me/messages/{messageId}

Intermittently, this returns:

HTTP 412 ErrorIrresolvableConflict

This appears to happen when Outlook and Graph modify or save the same active draft around the same time.

A limited retry reduces the frequency of the failure, but it does not remove the underlying race condition.

Questions

• Is retrying 412 / ErrorIrresolvableConflict the recommended handling strategy?
• Is there a supported synchronization mechanism before updating an active Outlook draft through Graph?
• Can an add-in determine when Outlook has finished saving or synchronizing the current draft?

---

5. Draft synchronization concern

We would also like to understand what happens in the opposite ordering:

1. Graph update succeeds
2. Outlook performs another background save
3. The draft changes again before the final send

We have not confirmed any data-loss scenario, but we would like to understand what guarantees are provided when Outlook and Graph can both modify the same active draft.

Questions

• Can a successful Graph update subsequently be overwritten by an Outlook background save?
• Is there any locking, change-key, versioning, or synchronization mechanism intended for this scenario?
• How can an add-in ensure that the final server-side draft is the version that gets sent?

---

Outlook on the web

We would also like to know whether the same recommendations apply to Outlook on the web, since similar draft synchronization behavior may exist there as well.

---

Overall guidance requested

The general workflow being evaluated is:

User clicks Send
        ↓
OnMessageSend executes
        ↓
Draft is synchronized or updated
        ↓
Microsoft Graph operation is performed
        ↓
Outlook event must be completed safely

The approaches we have tested have the following trade-offs:

Approach	Observed behavior / concern
Graph operation + allowEvent: false	Prevents Outlook native send, but displays a dialog
Graph operation + allowEvent: false	Prevents Outlook native send, but displays a dialog
Do not call event.completed()	Outlook remains waiting for the add-in
item.close()	Displays an unsaved-changes confirmation
closeAsync({ discardItem: true })	Works silently, but is documented as unsupported in event handlers
Graph operation + allowEvent: true	No duplicate observed in testing, but the behavior is not clearly documented
Graph PATCH on active draft	Can intermittently return HTTP 412 due to concurrent updates

Questions for Microsoft

Could Microsoft please recommend the officially supported pattern for implementing this workflow in New Outlook for Windows?

In particular, we would appreciate clarification on the following:

1. How should an add-in stop Outlook's native send without showing a dialog?
2. How should a compose item be closed or dismissed from an OnMessageSend workflow?
3. Is closeAsync({ discardItem: true }) expected to work in event-based handlers?
4. What behavior should be expected when Graph changes the current draft and allowEvent: true is used?
5. How should 412 / ErrorIrresolvableConflict be handled when Outlook and Graph update the same draft?
6. Is there a supported synchronization mechanism for coordinating Outlook draft saves with Graph updates?

Our goal is to use only behavior that is officially supported and safe to rely on across future New Outlook updates.

Environment

• Platform: Windows
• Host: New Outlook for Windows
• Add-in type: Outlook Web Add-in
• Event: OnMessageSend / Smart Alerts
• Microsoft Graph: Draft update / send operations

A corresponding issue has also been raised in the OfficeDev/office-js repository.

What is the supported OnMessageSend pattern when updating and sending an Outlook draft through Microsoft Graph in New Outlook for Windows?

We are evaluating an Outlook Web Add-in using the Smart Alerts OnMessageSend event in New Outlook for Windows, together with Microsoft Graph operations on the current draft.

We are trying to understand the officially supported way to coordinate the Outlook send event with Microsoft Graph operations.

During our POC, we observed the following behaviors.

1. Graph send with allowEvent: false

After the Graph operation completes, we call:

event.completed({

This prevents Outlook from continuing its native send flow.

However, Outlook displays a Smart Alerts dialog because the original send operation has been blocked.

Question

Is there a supported way to stop Outlook's native send without showing a user-facing dialog when the message has already been successfully handled through Microsoft Graph?

---

2. Closing the compose item

If we do not complete the event immediately and instead try to close the compose item:

Office.context.mailbox.item.close();

Outlook displays an unsaved-changes confirmation.

We also tested:

Office.context.mailbox.item.closeAsync({

This closes the compose window silently in our testing.

However, the closeAsync documentation states that it is not supported in event-based handlers.

Questions

• Why does closeAsync({ discardItem: true }) currently work inside OnMessageSend in New Outlook for Windows?
• Can this behavior be relied upon?
• What is the officially supported alternative for closing or dismissing the compose item from an event-based handler?

---

3. Graph send with allowEvent: true

We also tested:

event.completed({

Since the message had already been handled through Graph, we expected Outlook's native send to potentially produce a duplicate message.

However, in our testing, only one message was delivered.

Questions

• What is the defined behavior when the current draft has already been sent or changed through Graph and allowEvent: true is subsequently returned?
• Does Outlook detect that the underlying draft has already been sent or changed?
• Is the absence of a duplicate message guaranteed, or is this undefined behavior that should not be relied upon?

---

4. HTTP 412 / ErrorIrresolvableConflict

We also update an active draft through Microsoft Graph using:

PATCH /me/messages/{messageId}

Intermittently, this returns:

HTTP 412 ErrorIrresolvableConflict

This appears to happen when Outlook and Graph modify or save the same active draft around the same time.

A limited retry reduces the frequency of the failure, but it does not remove the underlying race condition.

Questions

• Is retrying 412 / ErrorIrresolvableConflict the recommended handling strategy?
• Is there a supported synchronization mechanism before updating an active Outlook draft through Graph?
• Can an add-in determine when Outlook has finished saving or synchronizing the current draft?

---

5. Draft synchronization concern

We would also like to understand what happens in the opposite ordering:

1. Graph update succeeds
2. Outlook performs another background save
3. The draft changes again before the final send

We have not confirmed any data-loss scenario, but we would like to understand what guarantees are provided when Outlook and Graph can both modify the same active draft.

Questions

• Can a successful Graph update subsequently be overwritten by an Outlook background save?
• Is there any locking, change-key, versioning, or synchronization mechanism intended for this scenario?
• How can an add-in ensure that the final server-side draft is the version that gets sent?

---

Outlook on the web

We would also like to know whether the same recommendations apply to Outlook on the web, since similar draft synchronization behavior may exist there as well.

---

Overall guidance requested

The general workflow being evaluated is:

User clicks Send
        ↓
OnMessageSend executes
        ↓
Draft is synchronized or updated
        ↓
Microsoft Graph operation is performed
        ↓
Outlook event must be completed safely

The approaches we have tested have the following trade-offs:

Approach	Observed behavior / concern
Graph operation + allowEvent: false	Prevents Outlook native send, but displays a dialog
Do not call event.completed()	Outlook remains waiting for the add-in
item.close()	Displays an unsaved-changes confirmation
closeAsync({ discardItem: true })	Works silently, but is documented as unsupported in event handlers
Graph operation + allowEvent: true	No duplicate observed in testing, but the behavior is not clearly documented
Graph PATCH on active draft	Can intermittently return HTTP 412 due to concurrent updates

Questions for Microsoft

Could Microsoft please recommend the officially supported pattern for implementing this workflow in New Outlook for Windows?

In particular, we would appreciate clarification on the following:

1. How should an add-in stop Outlook's native send without showing a dialog?
2. How should a compose item be closed or dismissed from an OnMessageSend workflow?
3. Is closeAsync({ discardItem: true }) expected to work in event-based handlers?
4. What behavior should be expected when Graph changes the current draft and allowEvent: true is used?
5. How should 412 / ErrorIrresolvableConflict be handled when Outlook and Graph update the same draft?
6. Is there a supported synchronization mechanism for coordinating Outlook draft saves with Graph updates?

Our goal is to use only behavior that is officially supported and safe to rely on across future New Outlook updates.

Environment

• Platform: Windows
• Host: New Outlook for Windows
• Add-in type: Outlook Web Add-in
• Event: OnMessageSend / Smart Alerts
• Microsoft Graph: Draft update / send operations

A corresponding issue has also been raised in the OfficeDev/office-js repository.