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.
Allow Outlook add-ins to detect when user is composing during read-mode activation
When an Outlook add-in is opened via the message action bar while a user is composing a reply, the add-in loads in read mode. However, the add-in has no way to detect that the user is actively composing, which prevents any compose-specific functionality from working correctly. Steps to Reproduce Open Outlook and select an email message Click Reply to start composing a reply Click an add-in button from the message action bar The add-in loads with the /read URL route The add-in cannot determine whether the user is composing or just reading Expected Behavior The add-in should have a way to detect that a compose window is open so it can adapt its behavior or redirect to the appropriate compose mode. Actual Behavior The add-in loads in read mode with no API or mechanism to detect that the user is composing. The URL alone (/read) is insufficient to determine the actual user context. Root Cause Currently, there is no Office.js API that allows a read-mode add-in to detect whether a compose window is open for the current message. The manifest also does not provide context-aware routing capabilities. Requested Solution Please provide one or more of the following: An Office.js API that allows read-mode add-ins to detect if a compose window is active for the current message A way for the manifest to route action bar buttons contextually (to /compose if composing, /read if reading) Additional context information passed to the add-in so it knows which entry point was used and the actual user context Without this, any add-in that supports both read and compose functionality cannot provide a consistent user experience when opened from the message action bar during compose.
Add Workbook.calculate() to avoid recalculating all open workbooks
Today, the Office.js API exposes Excel.Application.calculate(calculationType), but it recalculates all currently opened workbooks in Excel. This becomes a performance and UX problem when users have multiple large workbooks open and an add-in needs to trigger calculation only for the workbook it’s running in. Request: Please add a workbook-scoped calculate API that recalculates only the active workbook, while reusing the existing Excel.CalculationType enum (recalculate, full, fullRebuild). Example API shape (one option): await Excel.run(async (context) => { context.workbook.calculate(Excel.CalculationType.recalculate); await context.sync(); }); This would preserve the current semantics of Excel.CalculationType while avoiding unintended recalculation of unrelated open workbooks (the current Application.calculate behavior).
Improving Excel Add-in API failures when in CellEditMode
Hello Microsoft Add-in team! I'm developing an Excel Add-In and have some suggestions relating to Excel.ErrorCodes.invalidOperationInCellEditMode. I'm finding that having the Excel Add-In APIs all either delay execution or throw the CellEditMode error while the user is in cell edit mode is making for a bad user experience in my Add-in. For example, at launch, my Add-In TaskPane needs to check the workbook CustomXML for metadata specific to my Add-In. But (if I'm not mistaken) I can't do that if the user is in cell edit mode. It seems I have to call the API, get a failure, then tell the user something like "The Add-In is waiting for you to finish editing your cell" and try again with { delayForCellEdit: true }. It's messy. So my suggestions are three, supposing CellEdit errors are in some cases necessary: 1.) Can we make it so that not *every* API call is blocked when in CellEdit mode? For example, why should reading/writing CustomXML be blocked because of cell editing? Is the error being thrown unnecessarily in some cases? 2.) Can we add a new "addHandlerAsync" event for CellEditMode enter/exit, to allow a TaskPane to disable buttons that aren't going to work while the user is in CellEdit mode? Disabling such buttons (with explanation, of course) could make for a better TaskPane user experience than having the user clicking a button and getting an error. (I do realize the error could still happen, as change events seem to fire on a delay, but they might at least happen less frequently!) (For example, in my Word Add-In, I am enabling/disabling buttons based on user's content selection, and the experience seems to be nice, even with the slight delay.) 3.) Can we add another callback param to "Excel.run({ delayForCellEdit: true }, ...)" so the developer can know that their API calls will be delayed and the user can be prompted to exit CellEditMode? (That might clean up me having to try, catch and then retry with delay?) I'm sure you've thought about all this more than I have, but these are the issues I'm running into. Thanks for your time and keep up the good work!Outlook Addin - enable Clipboard API
Outlook Addin currently does not support Clipboard API, because containing iframe does not have appropriate permissions. Currently the only other option to copy text is to use deprecated document.execCommand("copy"). For more information, please see this issue: https://github.com/OfficeDev/office-js/issues/1991
Preserve Add-in signature HTML on Outlook for iOS across all clients
Summary When an Office Add-in inserts HTML into a message on Outlook for iOS (for example, an email signature), Outlook for iOS rewrites the inline CSS at the point the content is added to the message body. The rewritten CSS uses modern shorthand and the currentcolor keyword, which classic Outlook on Windows (the Word based rendering engine) does not render correctly. The result is that recipients opening the message in classic Outlook on Windows see missing or incorrect styling, most visibly missing border colors on signature elements. The same message renders correctly when opened in Outlook on the web, new Outlook for Windows, Outlook for iOS, and Outlook for Android. Only classic Outlook on Windows is affected, because only the Word rendering engine fails to interpret the rewritten CSS. Who this affects Any organisation using a third party signature Add-in (or any Add-in that injects styled HTML) on Outlook for iOS, whose recipients include users of classic Outlook on Windows. This is a large population: classic Outlook on Windows is still the default client in many enterprises. We are raising this on behalf of a significant number of affected customers who currently have no workaround. What we observed We insert this HTML into the message via the Add-in: <td align="left" style="padding:12px; border-top:none; border-right:none; border-bottom:none; border-left:solid 8px #F5F736; vertical-align:top; font-family:Calibri,Arial,sans-serif;"> Outlook for iOS rewrites it, before it is committed to the message body, to: <td dir="ltr" align="left" style="white-space: nowrap; border-width: medium medium medium 8px; border-style: none none none solid; border-color: currentcolor currentcolor currentcolor #F5F736; padding: 12px; vertical-align: top;"> Two behaviours are problematic: The individual border-top, border-right, border-bottom, border-left declarations are merged into border-width, border-style, and border-color shorthand. The merged border-color uses the currentcolor keyword for the three unset sides. Classic Outlook on Windows does not honor currentcolor reliably in this context, and its handling of this particular shorthand combination drops or miscalculates the actual colored side. The colored border the sender intended is not displayed to the recipient. Why this is a problem specifically for Add-ins Authors of Office Add-ins cannot control what the host client does to HTML after body.setSignatureAsync, body.setAsync, or equivalent insertion APIs are called. The HTML we provide is valid, and it renders correctly on every other Outlook surface. The rewrite is happening inside Outlook for iOS, silently, and we have no API to opt out of it. Reproduction Build a simple Outlook Add-in that inserts the HTML snippet above into a new mail message using the standard Office JS body insertion APIs. Send the message from Outlook for iOS (tested on iOS 18.3.2, Outlook for iOS 4.2513.1). Open the sent item in Outlook on the web or Outlook for iOS: the yellow left border renders correctly. Open the sent item in classic Outlook on Windows: the left border color is missing. Prior report This was previously reported against Office JS on GitHub: https://github.com/OfficeDev/office-js/issues/6521. The response was that the issue will not be fixed in the short term, and the recommendation was to raise a Tech Community item so the team can gauge demand. That is what this post is for. What we are asking for Ideally one of the following: Stop Outlook for iOS rewriting inline CSS that was supplied by an Add-in through the supported insertion APIs. Pass the author's HTML through unchanged, or If normalisation has to happen, avoid emitting currentcolor and avoid collapsing per side border properties into shorthand in ways that known Outlook rendering engines cannot interpret, or Publish a documented, supported HTML and CSS subset that is guaranteed to round trip across all Outlook clients (including the Word rendering engine in classic Outlook on Windows), so Add-in authors can target it deliberately.
Ability to dynamically change ribbon button at runtime
Our ribbon button actions are awkward! We need the ability to interact with them more dynamically at runtime. Ideas: Change Office.Ribbon.RequestUpdate() so that it can change a ribbon button's label at runtime, like the "Protect Sheet"/"Unprotect Sheet" button in the Review tab. Give us the option to create toggle buttons in the manifest and in contextual tabs, like Excel's native "Filter" button in the Data tab, or the "Bold" button. Change Office.Ribbon.RequestUpdate() so that it can remove a ribbon button, or change its icon, at runtimeAbility to disable Copilot Agent / Edit functionality on a sheet + Copilot events
We developed an Excel addon which intercepts certain Excel events - sorting of Excel tables, editing cells, etc. on special add-on managed sheets. This functionality is broken when Copilot Agent/Edit starts modifying the sheet. Would it be possible to disable Copilot Agent/Edit mode on particular sheets in full and to provide rich API to intercept Copilot's actions?Get selected chart element in Excel JS API
We need to read the data point when a user clicks on one of the parts of a bar chart or pie chart. Something like getSelectedChartElement() that points to the underlying cell range where the data point resides. Or a Chart event whenever a chart element is selected.
