Office.js API Request: Context-Anchored Sandboxed Web Surfaces for Excel, Word, and PowerPoint
Office Add-ins currently provide cross-platform task panes, dialogs, and add-in commands. However, developers cannot display sandboxed and interactive web content anchored to a selected document object without inserting a native shape, image, text box, content control, or other persistent Office object. I propose a cross-platform Context-Anchored Web Surface API for Excel, Word, and PowerPoint. The API should allow an Office Add-in to attach a sandboxed web card to the current selection or to a supported document object, including: Excel ranges, table cells, charts, images, or shapes Word text ranges, paragraphs, table cells, images, or content controls PowerPoint text ranges, shapes, images, table cells, or slides The surface should not become part of the native document drawing layer unless the developer explicitly requests conversion to a document object. Office should manage: Position relative to the anchor Focus and keyboard interaction Security boundaries Z-order and clipping Scrolling and zoom behavior Word document reflow PowerPoint editing and presentation modes Surface lifetime and restoration Cross-platform behavior The proposed API should provide: A unified cross-host anchor abstraction Persistent anchor identifiers Selection, session, document, and manual lifetime modes Preview, interactive, and editor interaction modes Sandboxed iframe or WebView content Automatic viewport-aware placement Host-managed repositioning during scrolling, zooming, layout changes, or document reflow Explicit print, PDF export, image export, and presentation rendering policies Message passing between the Office Add-in runtime and the contextual surface Requirement-set detection across Windows, macOS, Office on the web, and supported mobile clients An example API could look like: Office.context.ui.contextualSurfaces.create({ anchor: Office.context.document.getSelectionAnchor(), source: { url: “https://example.com/context-card” }, placement: { preferred: “right”, keepInViewport: true, followAnchor: true }, interaction: { mode: “interactive”, dismissOnEscape: true }, lifetime: { mode: “document”, restoreOnOpen: true }, rendering: { mode: “authoringOnly”, includeInPrint: false, includeInExport: false } }); This would enable contextual experiences such as: Chemical compound and molecular structure cards Biomedical annotations Citation and literature tools Translation and terminology previews Financial and company data cards Educational explanations AI-assisted review tools Domain-specific document annotations Today, developers must choose between a fixed task pane and native document objects. A host-managed contextual web surface would provide a secure and consistent middle layer while preserving document integrity and cross-platform compatibility.
Support custom functions downstream of iterative (circular) calculation - currently return #CALC!
Office.js custom functions in Excel return #CALC! whenever any of their precedents involve a circular reference chain resolved by iterative calculation, even when the function itself is not part of the loop. (Tracked in https://github.com/OfficeDev/office-js/issues/4738, open since July 2024.) Many common financial usecases require iterative calculations as part of standard practices. As an example, average-balance interest with iterative calculation is the mainstream convention in leveraged-finance modeling. Interest expense depends on the average debt balance, which depends on cash paydown, which depends on interest expense. Analysts across banking and private equity resolve this loop with Excel's iterative calculation setting. The same pattern appears in revolver/cash-sweep modeling and fund fee/NAV calculations. These workbooks worked for decades with XLL and VBA UDFs. Any custom function consuming a model's outputs (e.g. an add-in function that writes results back to an external platform) is by definition downstream of the circular chain, so it always fails in these models. We've verified: a custom function with literal arguments works; the same function with an argument fed from the converged loop returns #CALC!; severing the dependency with IF(TRUE, value, FN(...)) makes it work again. This blocks migration from legacy XLL/VBA add-ins to the modern Custom Functions API for financial-modeling users. The ask: custom functions downstream of a circular chain should evaluate against the loop's converged values after the iteration pass completes — matching legacy XLL/VBA UDF behavior. Custom functions don't need to participate in the iteration itself.
Native staged/canary rollout for Office Add-in manifests (Centralized Deployment/Integrated Apps)
Summary There is no supported way to roll out an Office Add-in manifest change to a small percentage or ring of users first, monitor health, and automatically roll back on failure. A manifest-level regression reaches 100% of a tenant at once, and rollback is a slow manual re-deploy. We request native staged/canary rollout for add-in manifests, matching capabilities Microsoft already ships for other products. Category Feature request / platform capability gap — Add-in deployment & management (Centralized Deployment / Integrated Apps in the M365 admin center; also relevant to Microsoft Marketplace). This is a deployment-platform gap, not an Office.js client-API defect. Applies to Outlook add-in using event-based activation (OnMessageSend / Smart Alerts). Both the add-in-only (XML) manifest and the unified manifest for Microsoft 365. Distribution via Centralized Deployment / Integrated Apps and via Marketplace. Motivation (real scenario) We ship a security/compliance add-in (event-based, OnMessageSend Smart Alerts) to enterprises with thousands of mailboxes. Today, any manifest-level change — a new/changed event, requirement set, add-in command, endpoint, permission, or scope — is delivered to the entire tenant simultaneously. There is no supported mechanism to: expose the new manifest version to a small % or pilot ring first, watch activation/error telemetry, and automatically halt and roll back if health degrades. Blast radius is the whole tenant; rollback means manually re-deploying the previous manifest, which propagates slowly (24–72h ribbon propagation; event configuration is cached locally and syncs asynchronously). Microsoft's own https://learn.microsoft.com/office/dev/add-ins/resources/resources-office-add-in-known-issues — where an event-based-activation change caused Smart Alerts add-ins to block users from sending mail, requiring multiple restarts to recover — illustrates exactly the blast radius and recovery latency that a staged rollout would contain. What's missing (specifics) No percentage-based or ring-based rollout for a manifest version. Centralized Deployment assignment is manual and coarse — Everyone / specific users / groups only (https://learn.microsoft.com/microsoft-365/admin/manage/manage-deployment-of-add-ins). No telemetry-gated automatic promotion between stages. No one-click halt / automatic rollback to the previous manifest version. Changes to Events / permissions / scopes force admin re-consent and block users until granted (https://learn.microsoft.com/office/dev/add-ins/testing/testing-and-troubleshooting#add-in-wont-upgrade), so even manual group-phasing is disruptive for event-based add-ins. Marketplace updates are all-or-nothing and auto-propagate. What we've tried, and why it's insufficient Manual group-based phased assignment (Microsoft's documented "recommended rollout strategy"): no percentages, no automated health gating, no automated rollback; still forces re-consent for event/permission changes. Two parallel add-in registrations (pilot vs. prod): produces duplicate ribbon UI and doubles admin overhead, and for event-based add-ins both registrations fire on the same event — unacceptable. Web-layer feature flags on our own CDN: works well for code-only changes, but cannot canary anything that lives in the manifest (events, requirement sets, commands, endpoints, permissions). Requested capability Native staged rollout for add-in manifest versions in Centralized Deployment / Integrated Apps: Define rings or percentages (or a pilot group) for a new manifest version. Promote / expand scope in steps; automatic health signals (activation failures, JS errors, event-handler failures) that gate promotion. One-click halt and automatic rollback to the previous manifest version. Programmatic support (PowerShell / Microsoft Graph) so this integrates with CI/CD. Precedent — Microsoft already ships this pattern elsewhere Office Add-ins are the conspicuous gap. Comparable staged/canary rollout already exists for: Microsoft 365 Copilot connectors — "staged rollout" to a limited audience (up to 100 users / 15 groups): https://learn.microsoft.com/microsoft-365/copilot/connectors/staged-rollout Microsoft Store apps — "gradual package rollout" (percentage-based, with halt/finalize): https://learn.microsoft.com/windows/apps/publish/gradual-package-rollout Microsoft Entra ID — cloud-auth "Staged Rollout" (group-scoped): https://learn.microsoft.com/entra/identity/hybrid/connect/how-to-connect-staged-rollout OneDrive sync app — multi-ring rollout with telemetry-gated suspend: https://learn.microsoft.com/sharepoint/sync-client-update-process Impact / who benefits Every ISV shipping security/compliance/productivity add-ins, and every enterprise admin using Centralized Deployment. Reduces tenant-wide outages from add-in updates and enables safe CI/CD for add-ins. Environment Clients: Outlook on Windows (classic + new), Outlook on the web, Outlook on Mac. Requirement sets: 1.15. Questions for Microsoft Is native staged/canary rollout for add-in manifests on the roadmap? Is there any supported way today to (a) roll out a manifest change to a subset of users with automated rollback, and (b) canary an event-based / OnMessageSend manifest change without an org-wide re-consent that blocks users? If not supported today, please treat this as a feature request and point us to the correct intake (aka.ms/m365dev-suggestions or other).
Office.js API support for Power Query editing (enable Copilot & AI integration)
The Office.js API currently supports refreshing Power Query connections but provides no capability to read, create, edit, or delete Power Query (M code) definitions programmatically. Use Case — AI Assistant Integration: AI assistants (Microsoft Copilot, Claude, ChatGPT, etc.) interact with Excel via the Office.js API. Users increasingly expect these tools to help build and maintain Power Queries. Currently, AI assistants cannot: Read existing M code to understand or explain data transformations Create new Power Queries from natural language descriptions Edit or debug problematic queries Delete obsolete queries Update connection strings, file paths, or query parameters programmatically This represents a significant gap given Microsoft's investment in Copilot for Excel and the broader AI-assisted productivity vision. Requested API Capabilities: Read M code from existing queries Create new queries programmatically Edit M code for existing queries Delete queries Modify query parameters (file paths, connection strings) Access query metadata (name, last refresh, error status, dependencies) Impact: Enables Copilot and third-party AI tools to fully assist with Power Query authoring Democratizes Power Query by letting AI explain and write M code for non-technical users Aligns with Microsoft's AI-first strategy for productivity tools Platform: All platforms (Windows, Mac, Web)
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).
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?
