mbeer's avatar
mbeer
Copper Contributor
Dec 06, 2025
Status:
New

Enable displayNewAppointmentForm(Async) in Outlook Compose mode for calendar add-ins

I’m building an Outlook add-in that helps users plan public transport journeys around their meetings and create corresponding calendar entries. The add-in is called "OutlookSwissPT-OfficeJS" and uses the Swiss public transport timetable to propose outbound and return connections for a given appointment.

The project is open source on GitHub; you can find it by searching for "OutlookSwissPT-OfficeJS" or for the repository "mbeer/OutlookSwissPT-OfficeJS".

Example usage of displayNewAppointmentForm(Async) in this add-in can be found in the file "src/taskpane/taskpane.js".

Today, the add-in relies on Office.context.mailbox.displayNewAppointmentForm and displayNewAppointmentFormAsync to open new pre-filled appointments for selected connections, for example an outbound journey to a meeting or a return journey from that meeting.

According to the Office JavaScript documentation and the Mailbox requirement set tables, both methods are only available in Read mode, not in Compose mode. In the requirement set tables, the applicable Outlook mode for displayNewAppointmentForm and displayNewAppointmentFormAsync is listed as "Read" only.

This has a few practical consequences. In Outlook on the web, calendar events that I own or organize are typically opened directly in Compose mode from the week view, so there is effectively no "pure" Read mode user interface for my own events. In this situation, my add-in can still show its task pane, but it cannot use displayNewAppointmentForm(Async) at all, because those APIs are not exposed in Compose mode. The same limitation applies in other Compose scenarios, for example when creating a new meeting or editing an existing one in Outlook Desktop or the new Outlook.

I have implemented a workaround by detecting Compose versus Read mode in my task pane. In Compose mode, the add-in offers a limited mode. The user can still run the timetable search and see the list of suggested connections, but the buttons to insert a connection as a calendar appointment are hidden or disabled. A banner explains that automatic appointment creation is not available in Compose mode and that the user must either manually copy the details or save the appointment, reopen it from the calendar in Read mode in a supported client, and then run the add-in again.

While this workaround is functional, it is not ideal from a user experience point of view. The most natural moment to plan journeys is exactly when the user is creating or editing a meeting in Compose mode.

REQUESTED CHANGE

Please consider extending the contract of displayNewAppointmentForm and displayNewAppointmentFormAsync so that they are also available when an add-in is running in an appointment or message Compose context, not only in Read. An add-in in Compose mode should be able to open a separate new appointment form, for example for a travel connection, in the same way it can today from Read mode.

I am not asking to modify the currently edited appointment in place. I am asking to allow an add-in that is active in Compose mode to open additional new appointment forms via the existing APIs, with the same parameters and behavior as in Read mode.

WHY THIS MATTERS

Travel and logistics helper add-ins, such as a public transport timetable, flight picker, or travel time calculator, are a very natural fit for meeting creation and editing workflows. Restricting displayNewAppointmentForm(Async) to Read mode forces users into an artificial workflow where they first have to create and save the meeting, then close it, reopen it from the calendar in Read mode, and only then can the add-in open new appointments for the journeys around that meeting. In Outlook on the web, where own events are opened directly in Compose, this is particularly confusing, because users do not even see a clear "Read mode" state for their own appointments.

Allowing displayNewAppointmentForm(Async) in Compose mode, to open new appointments and not to change the current draft, would make calendar-related add-ins much more intuitive and powerful. It would reduce user confusion and support load for add-ins that currently have to explain why some scenarios are artificially limited. It would also align better with the mental model of a user who is creating or editing a meeting and would like the add-in to create related calendar entries for travel.

If there are technical or user experience constraints that make this difficult, it would already help to have an official statement or guidance on whether support for Compose mode is planned or explicitly out of scope.

No CommentsBe the first to comment