No programmatic way to pin the task pane for users
Your Environment Platform: PC desktop, Mac, Office on the web Host: Outlook Office version number: All supported versions Operating System: Windows, macOS Expected behavior The Office JS API should provide a programmatic mechanism to pin the task pane on behalf of the user — for example, via a manifest setting or a runtime API call — so that the task pane remains open and pinned without requiring manual action from each user. Current behavior There is no programmatic way to pin the task pane for users. Users must pin it manually via the UI. This results in an inconsistent experience, particularly for enterprise deployments where we need to ensure the add-in remains accessible without relying on individual user action. Context We need the task pane to remain pinned for all users automatically upon install or first launch. The current lack of a programmatic pin mechanism creates friction and support overhead, as users frequently close the task pane and do not know how to re-pin it. We are looking for either an existing API we may have missed, or confirmation that this is a platform gap so we can raise a feature request through the appropriate channel.
Support for Split Button in ribbon
We need a way to declare a split button (an action button with a drop down menu accessible by clicking the down arrow next to the button. (like. the Flags split menu in Outlook (button can clear the flag while dropdown menu can select a flag). The manifest could be a menu with an ExecuteFunction at the item level. If an execute function is present, the rendering is a Split-Button otherwise it's a classic menu. A example taken from New Outlook for MacOS. The split button exists, but it's unavailable to office.js add-ins.
Gracefully handle unavailability of Office.js
The reliance on Office.js (and its dependencies) delivered from the network proves to be challenging in some scenarios. While ideally the platform would support full offline use, I'm hopeful that there are some incremental improvements that could be made to address some of our challenges in the shorter term. As an example, our add-in hooks into Outlook's OnMessageSend, which inherently puts it on the critical path of the user experience when sending emails. In scenarios where the user's network is slow or unreliable, or in an event of an Azure CDN outage that makes Office.js unavailable or slow to be delivered, the user experiences a long wait while Office.js is loaded on message send. I should highlight that Outlook attributes this delay to the add-in: "Add-in X is taking longer than expected". I'd like to propose that the platform gives the add-in more control over the user experience in these cases. What this would look like for our OnMessageSend add-in is that the add-in would execute some code outside of the event handler (before Office.js finishes loading) to start a timer, and if the loading phase exceeds a timeout value defined in the add-in code then the add-in would instruct Outlook to conclude the processing of the event (similarly to how event.completed() is invoked inside an event handler). That last part would require some interface with Outlook that is available even if Office.js hasn't been fully loaded.Feature Request for Enhanced Outlook Add-in Surfaces
Feature Request for Enhanced Outlook Add-in Surfaces Request Title: Expandable/Pop-out Outlook Add-ins with Inline Compose/Reply Integration Products/Platforms: Microsoft Outlook Add-ins (Office.js) across Classic Outlook for Windows, New Outlook for Windows, Outlook for Mac, and Outlook on the web (OWA) Request Type: New extensibility capabilities / UI host surfaces for Outlook add-ins Priority: High (end-user productivity + adoption + enterprise usability) Background We use an Outlook add-in to integrate additional productivity tools into the email workflow to help users save time, reduce context switching, and improve execution quality. This is a core enablement pattern for enterprise users who spend significant time in Outlook. Today, our add-in runs primarily in the task pane, which has notable limitations in flexibility and available space. The current experience is increasingly cluttered and not user-friendly, especially for workflows that require richer UI, multiple steps, or contextual data. Additionally, the add-in is not seamlessly integrated into the new message compose and reply experience (i.e., the workflow is not inline with the compose/reply window), which limits usability for scenarios that must occur at the moment a user is authoring a message. Problem Statement Current task pane constraints lead to: Limited UI real estate (narrow layout, heavy scrolling, cramped forms, poor readability) No user-friendly expand/enlarge options to fit different workflows and screen sizes Reduced usability during compose/reply, where users need the tool inline with message authoring Lower adoption and productivity because the add-in experience feels disconnected and cumbersome In practice, users need more space and tighter integration at the exact point of work (compose/reply), without leaving Outlook or juggling multiple windows. Requested Features We request Microsoft to support the following add-in UI capabilities, ideally consistently across Classic Windows, New Outlook, and OWA: A) Expandable / Resizable Task Pane Allow users to resize/expand the add-in pane (wider layout; optional full-height behavior) Support a compact vs expanded mode with user preference persistence Outcome: Richer workflows become usable without redesigning into cramped layouts. B) Pop-out Add-in Experience Provide a supported pop-out window for the add-in (while maintaining context to the current item) Ensure pop-out works smoothly with enterprise policies and does not break the add-in lifecycle Outcome: Users can work with complex UI without sacrificing mail reading/authoring space. C) Inline Add-in Integration with Compose and Reply Enable add-in UI to appear inline within the compose/reply window (not just as a separate side pane) Support contextual actions/data entry during authoring (e.g., insert content, validate, attach artifacts, update records) Ensure consistent behavior for new compose and reply experiences Outcome: The tool is available at the moment users need it while writing responses, driving adoption and reducing errors. D) Add-in as a Mail Tab Provide a supported extension point for an add-in to appear as a tab in Mail, similar to “Focused/Other” Tab hosts a larger workspace for add-in workflows (e.g., triage/queue/workbench views) Outcome: A first-class workspace in Mail for workflows that don’t fit the task pane model. Key Enterprise Use Cases Multi-step workflows triggered from emails (triage, intake, approvals, routing) Rich forms and guided actions that are impractical in a narrow pane Compose/reply-time actions: insert approved templates/snippets, validate recipients/content, capture metadata, create/update tasks/records Dedicated mail workbench views via a tab for operational roles Acceptance Criteria Cross-client consistency: Classic Windows, New Outlook, and OWA supported with minimal divergence Next Steps for Microsoft Confirm roadmap/feasibility for: expandable task pane, add-in pop-out, inline compose/reply surface, and mail tab surface Provide recommended implementation model/APIs and opportunities for preview/early access for enterprise validation Screenshots for Reference
Add a Range API for Outlook add-ins
Word add-ins provide the Word.Range API, which allows precise manipulation of document content (selection, insertion, replacement, formatting). Outlook add-ins currently lack an equivalent API, making fine-grained interaction with the message body difficult or impossible. We propose adding a Range-like API for Outlook add-ins to enable: • Access to the current selection in the message body • Insert or replace text at a specific position This would significantly improve advanced authoring, productivity, and AI-assisted scenarios in Outlook. Example (conceptual) const range = Outlook.context.mailbox.item.getSelectedRange(); range.insertText("Hello world", Outlook.InsertLocation.replace); Reference Word Range API : https://learn.microsoft.com/en-us/javascript/api/word/word.range?view=word-js-preview
Enhanced Document Control/Protection APIs in Office.js for Word Add-ins
We are developing a Word add-in using Office.js and JavaScript APIs. Our use case requires advanced document control features, which are currently challenging to achieve within the existing Office.js framework. Here’s our feature request: Proposed Functionality: Based on the defined custom properties on a document via add-ins, provide APIs/commands/hooks to disable or override Word's default 'Save,' 'Save As,' and 'Share' options to prevent users from saving or sharing the document locally. Introduce additional APIs for implementing custom protection mechanisms within the add-in. Current Challenges: Achieving this functionality appears possible through VSTO add-ins, but they are not compatible with Office.js solutions. VSTO/.NET commands require complex workarounds, such as creating a separate .NET server to communicate with Office.js, which adds development complexity and affects efficiency. Request: We would greatly appreciate the introduction of built-in, efficient APIs in Office.js to handle document protection and control scenarios seamlessly without relying on external frameworks or services. This would significantly enhance the capability of modern web-based add-ins and improve the development experience for Word add-in developers.
Office Addin - First Letter Navigation in menus
Some UI components, such as dropdow lists, do support first letter navigation, i.e. lets the user navigate through the items of a list based on the first letter of the item's title. Here is a concreate example: In Word, go to File > Options > General > Office Background > Down arrow (to open the dropdown list). In here, if I press 'C' once, I land on 'Calligraphy'. If I press 'S' once, I land on 'School Supplies', press 'S' a second time I land on 'Spring', press 'S' a third time I land on 'Starts', and so forth. However, such navigation mechanism is not supported for menu components. For example: In Word, go to Insert > Link > Recent items. I have a long list of recently accessed Word of Excel documents (let's call them Document_1, Document_2, ..., Document_n). When I press 'D', I get an error beep and nothing happens. Indeed some items are linked to a keytip, but I cannot navigate the list as described above. We are developing some VSTO add-ins for Excel, Outlook, Powerpoint and Word for visually-impaired users. For each, we are creating a simplified ribbon that provides them with a subset of functionalities. For example: <?xml version="1.0" encoding="UTF-8"?> <customUI xmlns="http://schemas.microsoft.com/office/2009/07/customui" onLoad="Ribbon_Load"> <ribbon startFromScratch="true"> <tabs> <tab id="MainMenu" getLabel="GetMenuLabel" visible="true" keytip="M"> <group id="FunctionsGroup" getLabel="GetGroupLabel"> <menu id="FileFunctions" keytip="F" getLabel="GetMenuLabel" > <!--Action_1--> <button id="Action_1" getLabel="GetButtonLabel" getImage="GetButtonImage" getScreentip="GetScreenTip" getSupertip="GetSuperTip" onAction="OnActionButton" /> <!--Action_2--> <button id="Action_2" getLabel="GetButtonLabel" getImage="GetButtonImage" getScreentip="GetScreenTip" getSupertip="GetSuperTip" onAction="OnActionButton" /> <!--Action_N--> <button id="Action_N" getLabel="GetButtonLabel" getImage="GetButtonImage" getScreentip="GetScreenTip" getSupertip="GetSuperTip" onAction="OnActionButton" /> .......... </menu> </group> </tab> </tabs> </ribbon> </customUI> Having first letter navigation work in menus would be a major gain in terms of accessibility throughout all available Office menus (which there are hundreds and more shared between all Office apps). My questions: Are there plans to support first letter navigation for menu components? Is there a way we can attach key event handlers to UI components such as menus that are created from a ribbon.xml file?Add an OptionPane for add-ins preferences
In each Office Settings... having a add-ins section where all installed add-ins with a declared OptionPane would appear. Selecting the OptionPane would display it aside the list of add-ins with the one being displayed highlighted. In the OptionsPane, the add-ins would be able to have an interface to configure its parameters (For example, for a Zip based add-ins, the user would be able to set the compression method or the default compression level). Another example:for a filtering add-ins, you could select which mailbox or which folder it applies to. The declaration in manifest would be similar to TaskPane, but it would be displayed in a different context. TaskPane is a bad place for that and buttons is not a better place either. Settings should be in an unique place: Settings...
Conditionally load Add-in on document load
Right now with our PowerPoint office add-in we are loading the add-in during document open time using office.addin.setStartupBehavior(Office.StartupBehavior.load). For the users who already have the add-in, the experience is great when they open the document. But, for others who don't have the add-in they are getting an error popup "This add-in is no longer available: ..." when they open the document that is saved with the office add-in. Can you add some behavior to conditionally load the add-in in the document only if the user has it.
