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).
Context menu items added with the id ContextMenuCell do not appear in the context menu of a table
In our addin meant for Excel, we define a context menu item with the id of ContextMenuCell. The problem is the option is not available when the user right clicks in an Excel table. This is an issue since we desire to use the item in the table as context for our custom context menu item. We don't necessarily need a separate id for context menu options in a table, just displaying the same options defined as ContextMenuCell in that context menu would be sufficient.
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)
Outlook 365 for Mobile app - Compose window support for Office JS add-ins
We are exploring the new Office JS add-ons model for Outlook for mobile apps and wanted to integrate our product with iOS/Android apps. While exploring the new Office JS model, we didn't see any way to integrate the product with compose window. Task-pane or commandBar way of integration is missing for compose window. Compose window task-pane or commandBar integration is common use case among iOS/Android users. While composing emails, the following use cases are common in industry: Users want to insert documents or attach emails from 3rd part repository or storage or from content management software. When user sends an email, they want to keep a copy of the email in the repository also Currently these use cases are not possible with add-in model. But it is supported in desktop version as well as web version of add-ins. Without these use cases support, users wont adapt our solutions. So this is required for more user adaptability.Changing the from/sender address in a Compose Scenario
Hi everyone! Based on a response from the Outlook Add-ins Team - MSFT: https://stackoverflow.com/a/67630922/833060 Our customers use different shared email addresses to communicate with different clients. With the current outlook-web-addins API we can warn them if they use an unusual sender address for a given message body or recipient address. But we cannot automatically suggest the most likely sender address when they reply to an email. For the recipients, e.g. the `to` address, we can just invoke: Office.context.mailbox.item.to.setAsync( [ { displayName: "Allie Bellew", emailAddress: "allieb@contoso.com" } ], result => console.log(result)); But the same is not possible for the `From` field. Since in Outlook Web they can pretty much set the sender to an arbitrary value, so long as the mail server will accept it, we propose to expose this functionality in the API as well. Thank you for your response and all the best, Pascal
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).
