Feature Request: Expose rowOutlineLevel as readable/writable on Excel.Range in office.js
SUMMARY Excel VBA has long supported Range.OutlineLevel as a read/write property for inspecting and setting row or column grouping levels. Office.js currently has no functional equivalent. We are requesting that rowOutlineLevel and columnOutlineLevel be exposed as functional read/write properties on Excel.Range. CURRENT OFFICE.JS LIMITATION Office.js provides Range.group() and Range.ungroup() starting with ExcelApi 1.9. However, there is currently no reliable way to read or restore the outline/grouping level of a row or column. Example: await Excel.run(async (context) => { const range = context.workbook.worksheets.getActiveWorksheet().getRange("A5"); range.load("rowOutlineLevel"); await context.sync(); console.log(range.rowOutlineLevel); // undefined range.rowOutlineLevel = 1; await context.sync(); // No error, but no effect }); We verified this across ExcelApi requirement sets through 1.21, ExcelApiDesktop 1.1, and Preview APIs. rowOutlineLevel returns undefined after load() and context.sync(). Setting rowOutlineLevel has no effect. The same behavior occurs when using getEntireRow(). rowOutlineLevel and columnOutlineLevel are not exposed in the documented requirement sets. VBA / COM PARITY Excel VBA already provides this functionality through Range.OutlineLevel. Read example: level = Worksheets("Sheet1").Rows(2).OutlineLevel Set or restore example: Worksheets("Sheet1").Rows(2).OutlineLevel = 1 VBA also provides Worksheet.Outline, including ShowLevels, SummaryRow, and SummaryColumn. Capability comparison: Read grouping level: VBA: Range.OutlineLevel Office.js: Not available Set grouping level: VBA: Range.OutlineLevel = n Office.js: Not available Apply grouping: VBA: Range.Group Office.js: Range.group() Remove grouping: VBA: Range.Ungroup Office.js: Range.ungroup() Query or control outline structure: VBA: Worksheet.Outline Office.js: No equivalent BUSINESS IMPACT Our Excel add-in manages Multi-Dimensional Report (MDR) sections that use row grouping for collapse and expand behavior. During refresh and mapping operations, we need to detect existing row grouping and outline levels and restore the grouping if operations such as range copies remove it. Without readable outline levels, we cannot determine which rows are grouped or at what level. Without writable outline levels, we cannot reliably restore the previous structure. Our current workaround requires users to manually fix grouping in Excel. This creates a poor enterprise experience and is a regression compared with our previous VBA-based automation. REQUESTED CHANGES Make rowOutlineLevel readable on Excel.Range so that it returns the actual outline level, such as 1, 2, or 3. Make rowOutlineLevel writable so that grouping levels can be restored programmatically. Provide equivalent read/write support for columnOutlineLevel. As a stretch goal, expose a Worksheet.outline API similar to VBA's Worksheet.Outline, including showLevels(), summaryRow, and summaryColumn. REFERENCES VBA Range.OutlineLevel: https://learn.microsoft.com/en-us/office/vba/api/excel.range.outlinelevel VBA Outline: https://learn.microsoft.com/en-us/office/vba/api/excel.outline Office.js Range.group() and Range.ungroup():https://learn.microsoft.com/en-us/javascript/api/excel/excel.range Office.js Preview APIs: https://learn.microsoft.com/en-us/javascript/api/requirement-sets/excel/excel-preview-apis ExcelApiDesktop 1.1: https://learn.microsoft.com/en-us/javascript/api/requirement-sets/excel/excel-api-desktop-1-1-requirement-set Office.js Range Grouping:https://learn.microsoft.com/en-us/office/dev/add-ins/excel/excel-add-ins-ranges-group
Word on Mac: bring Range.insertText() performance in line with Windows and Web
Summary Word.Range.insertText(text, "Replace") followed by context.sync() takes ~300 ms on Word for Mac desktop, versus ~4.5 ms on Windows and ~16 ms on Word on the web running on the same Mac. Full repro and measurements: OfficeDev/office-js#6721. Why it matters The cost is per round trip, not per character, so it scales with the number of edits. Add-ins that apply many individual range replacements — proofreading, terminology enforcement, review passes, template population — are fast on Windows and unusable on Mac from the exact same codebase. We build a writing-assistance add-in where a single correction pass means hundreds of replacements, and this gap is what currently prevents us from shipping it to our Mac users. Why we don't think this is expected behaviour This was filed as a bug and we were told it's by design and belongs here as an idea. We'd like to challenge that: Word on the web, in a browser, on the very same Mac, is roughly 19x faster than the native Mac host. That rules out hardware, macOS, and the general cost of the Office.js bridge, and points at the Mac host's insert/sync round trip specifically. What we're asking for Bring Range.insertText() round-trip latency on Mac into the same order of magnitude as Windows and the web. Failing that, publish the supported pattern for applying many replacements on Mac without paying the per-sync()cost. Document the current Mac performance characteristics in the Office.js docs.
Office.js provides no way to detect unsupported APIs within supported requirement sets
Problem Statement Currently, the only documented mechanism to check for annotations support is Office.context.requirements.isSetSupported('WordApi', '1.8'). However, on perpetual / non-subscription Office builds (e.g., Office 2021, Office 2024, LTSC), isSetSupported('WordApi', '1.8') evaluates to true, yet calling document.getAnnotations() immediately throws a runtime error (NotImplemented / GeneralException). There is currently zero way for an add-in to detect whether the user is on a perpetual build or whether getAnnotations() will fail before actually calling it. Why This Is Unacceptable Broken API Contract: isSetSupported() is advertised as the canonical capability-detection mechanism. Gating individual functions behind license tiers while marking the entire requirement set as "supported" defeats the purpose of requirement sets and leads to false positives. Impossible to Build Resilient UI: Add-ins cannot hide, disable, or adapt UI elements conditionally on startup because there is no API to check if getAnnotations (or the underlying license tier) is supported. No Viable Pre-Check: Developers cannot safely query capabilities upfront. Relying on blind runtime failures (try/catch on first invocation) produces broken user experiences, unneeded error telemetry, and brittle add-in logic. Required Solution Office.js must provide a reliable, deterministic way to detect whether an individual API or feature is usable before invoking it. We need Microsoft to implement at least one of the following: Method / Feature-Level Detection: Provide a granular capability check, for example: Office.context.requirements.isMethodSupported('Word.Document.getAnnotations') -> boolean or Word.isFeatureSupported('Annotations') -> boolean License / SKU Awareness: Expose host license properties on the context object so add-ins can identify perpetual/non-subscription environments upfront, for example: Office.context.license.isSubscription -> boolean or Office.context.license.skuType -> 'perpetual' | 'subscription' Reference GitHub Issue: https://github.com/OfficeDev/office-js/issues/5701
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
Provide an Official Offline Distribution Method for Office.js (Alternative to CDN)
According to the Microsoft documentation on accessing the Office JavaScript API library (https://learn.microsoft.com/en-us/office/dev/add-ins/develop/understand-the-javascript-api-for-office#access-the-office-javascript-api-library), the only official way to include Office.js in Office Add-ins is to load it from the CDN. While this works well for most scenarios, it creates a significant limitation for organizations that operate in offline or highly restricted network environments where external CDNs are not accessible. Previously, the BANNEDUSERNAME/office-js npm package (https://www.npmjs.com/package/%40microsoft/office-js) allowed developers to bundle Office.js with their add-ins, making offline deployments possible. Since this package has been deprecated, there is no longer an officially supported way to distribute Office.js in these environments. I would like to request one of the following: Bring back an officially supported npm package for Office.js. Provide another supported mechanism for bundling or self-hosting Office.js in offline environments. Publish official guidance for deploying Office Add-ins in air-gapped or disconnected networks. Supporting offline deployments would enable organizations with strict security requirements—such as government agencies, defense organizations, healthcare providers, and enterprises with isolated networks—to continue developing and deploying Office Add-ins using supported Microsoft solutions. This would greatly improve the developer experience and make the Microsoft 365 Office Add-ins platform accessible to a broader range of enterprise customers.
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)