Outlook classic: custom properties are not persisted after saveAsync

[sliekens]

I need to attach a custom property to an incoming messages when the message is viewed. For that, I use

1. Office.MessageRead.loadCustomProperties(callback, userContext)
2. CustomProperties.set(name, value)
3. CustomProperties.saveAsync(callback, asyncContext)

While the message is still being viewed, I need to make a call to a backend web API, where the mail and its custom properties are downloaded from Microsoft Graph.

The Problem

I noticed that Outlook (classic) does not sync the custom properties to Microsoft Graph after you call CustomProperties.saveAsync.

This behavior is actually documented in the remarks section:

In Outlook on Windows, custom properties saved while in compose mode only persist after the item being composed is closed or after Office.context.mailbox.item.saveAsync is called.

However, I have the same problem for received messages, and there is no Office.MessageRead.saveAsync method to force a sync. My custom property is only synced to Microsoft Graph after the user closes the message.

This is a problem because I need the value of the custom property in my server backend, while the user still has the message open.

Your Environment

• Platform: PC laptop
• Host: Outlook
• Office version number: Microsoft® Outlook® for Microsoft 365 MSO (Version 2407 Build 16.0.17830.20210) 64-bit
• Operating System: Windows 11

Expected behavior

After calling CustomProperties.saveAsync, I expect to find the values in Microsoft Graph shortly after.

Current behavior

The values only show up in Microsoft Graph after the user closes the message.

Steps to reproduce

1. Open any received message in your personal inbox
2. do Office.MessageRead.loadCustomProperties
3. do CustomProperties.set('time', Date.now().toString());
4. do CustomProperties.saveAsync
5. Observe the custom properties of the message in Microsoft Graph

Link to live example(s)

Sorry, it's an internal app.

Provide additional details

Ask away.

Context

Ask away.

Useful logs

There is not really any relevant log, as it is not an error per se.

[kwame-ansong]

Thanks for reporting this issue.
While the behavior you are observing is as expected, I have opened an internal tracking item to discuss this issue.
Reference # 9377936.
We will follow up soon with an update on this work item.