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
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).
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.
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 ReferenceAbility to save settings in Excel workbook without clearing Undo stack
Both the Office API `Office.context.document.settings.saveAsync()` and the Excel API `context.workbook.settings.add(key, value)` clear the undo stack when called. Undo is very important for editing data in Excel The Excel JS API documentation says that https://learn.microsoft.com/en-us/office/dev/add-ins/excel/excel-add-ins-undo-capabilities#unsupported-apis, but we have to tell our users that this is not true because the settings in the workbook cannot be saved without clearing undo. One of the following needs to happen: When `Office.context.document.settings.saveAsync()` is called, undo should not be disabled Or the newer Excel JS API's `context.workbook.settings.add()` should not disable undo 3. Or provide a `workbook.onSave` event, so that we can call settings.saveAsync() only when the workbook is saved. That may somewhat mitigate the damage by reducing the number of times that Undo. In our current implementation, it is constantly clearing the Undo stack, so putting it in a workbook `onSave` event would actually help a little with or without AutoSave on.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.
German Excel Support Pages – Surprised by Multiple Errors
Dear Microsoft Community, While studying the financial functions in Excel, I was surprised to notice that several German-language support pages contain errors — such as incorrect translations, English function names, non-working example formulas, wrong results, and some spelling mistakes. I enjoy working with this material and would be happy to assist in reviewing and correcting these pages on a paid, freelance basis. I realize this may not be the exact place for such an offer, so I would greatly appreciate it if someone could point me to the right contact person or department at Microsoft. Thank you very much for your help! TheoTags can't be exported / imported for slides using .exportBase64().
As can be seen in https://github.com/OfficeDev/office-js/issues/5989 https://github.com/OfficeDev/office-js/issues/6104 Tags on Powerpoint Slides/Shapes/Presentation currently are not exported or imported when running exportBase64 on a slide, essentially killing a very large part of the functionality that they would otherwise enable. It would be great if this could be added soon 🙏.