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 🙏.
Ability to Assign Custom Properties or Unique IDs to Individual Cells
Summary I'd like to request support for assigning custom metadata — such as unique IDs or arbitrary key-value pairs — directly to individual cells in Excel using the Office.js API. Why This Matters Currently, developers must rely on workarounds like named ranges, hidden metadata sheets, or cell notes to simulate per-cell identifiers. These approaches are either limited, fragile, or not scalable for large applications. Native support for cell-level metadata would unlock powerful use cases: Dynamic form builders Cell-level validation engines Workflow tracking Data lineage and audit trails Integration with external systems via stable cell references Proposed API Concept range.customProperties.add("id", "cell_001"); const id = range.customProperties.getItem("id").value; Or even: range.metadata = { id: "cell_001", status: "approved", validator: "admin" }; Benefits Eliminates reliance on fragile naming conventions Enables scalable, structured metadata management Improves developer experience and app robustness Alternatives Considered Named ranges: limited and global scope Notes/comments: visible to users, not structured Hidden metadata sheets: hard to maintain Custom XML parts: complex and not cell-specific Request Please consider adding support for cell-level metadata or custom properties in a future version of Office.js. Even a lightweight key-value store per cell would be a game-changer.
Feature Request: Add error/rejection support to Office.onReady() for network/dependency failures
Description Currently, when Office.js loads but one of its dependent resources (such as office_strings.js) fails to load due to network issues or blocking, the Office.onReady() promise never resolves or rejects. This leaves developers without a reliable way to detect missing dependencies. Instead of relying on timeouts or log messages, it would be very helpful if Office.onReady() provided an error callback or rejection in these scenarios. Why this matters: Helps developers handle production failures gracefully. Avoids arbitrary timeouts/workarounds to detect missing dependencies. Provides parity with modern async practices where promises resolve or reject deterministically. Enables better telemetry/analytics by explicitly knowing why initialization failed. Suggested Approach: If a required dependency fails to load, Office.onReady() should reject with an error describing the missing dependency. Alternatively, provide an event/callback (e.g., Office.onError) that developers can subscribe to. Example: Office.onReady() .then(info => { console.log("Office.js initialized:", info); }) .catch(err => { console.error("Office.js failed to initialize:", err); // custom fallback handling }); Impact: This would improve developer experience significantly and make add-ins more resilient in real-world network environments.Add viewportChanged event to Word JavaScript API
In Word add-ins, we often need to react to changes in the user's viewport (scrolling, zooming, etc.). Currently, there's no event to detect when the visible pages change. A viewportChanged event on Word.Pane or Word.Window would allow developers to optimize performance and create dynamic experiences based on what the user is viewing.