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).
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.
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! Theo
Tags 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 🙏.
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.
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.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.
Limitation with Static AppDomain Entries in Office Add-in Manifest
As outlined in the [Microsoft documentation](https://learn.microsoft.com/en-us/javascript/api/manifest/appdomain), trusted domains must be explicitly declared in the Office Add-in manifest using the <AppDomain> element. A trusted domain allows: - Pages, routes, or other resources in that domain to be opened directly in the root task pane on desktop Office platforms (note: this does not apply to Office on the web or dialog APIs). - Pages in that domain to make Office.js API calls from IFrames within the add-in. We are currently developing a first-party native Excel Add-in as part of a strategic partnership. However, our architecture requires support for customer-specific subdomains, such as: ``` <AppDomain>https://customer1.company.com</AppDomain> <AppDomain>https://customer2.company.com</AppDomain> <AppDomain>https://customer3.company.com</AppDomain> <AppDomain>https://customer4.company.com</AppDomain> ``` This list is dynamically growing, making it infeasible to maintain a static list of subdomains in the manifest. Each manifest update would require re-submission through AppSource, creating significant operational overhead and slowing down delivery. Because of this limitation, we’re forced to distribute customer-specific manifests and rely on M365 tenant admins to install the add-in manually—introducing friction and reducing discoverability for users. We propose enabling wildcard support for <AppDomain> entries in the manifest, e.g.: ``` <AppDomain>https://*.company.com</AppDomain> ``` This would allow all subdomains under company.com to be trusted without requiring individual enumeration, simplifying deployment and scaling while preserving security. This limitation has been highlighted and highly upvoted by the developer community in the following feature requests: - https://techcommunity.microsoft.com/idea/microsoft365developerplatform/add-in-manifest-allow-wildcards-for-app-domains/4162573 - https://techcommunity.microsoft.com/idea/microsoft365developerplatform/support-wildcards-for-appdomains-in-office-add-in-manifests-to-support-sub-domai/2312326Programmatically set the cursor (caret) to a specific location in an e-mail
Describe your scenario We are writing an addin for One Outlook where we place a signature text in the body of an e-mail. What is the problem to solve? The signature text we are placing is added correctly, but the cursor (caret) is placed at the bottom of the inserted text. We would like to control where the cursor (caret) is placed after we inserted the text. We have tried the following ideas: Using setSelectedDataAsync to dynamically insert content immediately after the marker. Manipulating the HTML with getAsync and setAsync to simulate the desired cursor position. Adding selectable elements, such as a span with a zero-width space, to force the cursor to position itself at the marker. Using prependAsync to insert content at the beginning of the body as an alternative to controlling the cursor. Implementing JavaScript methods like this: function setCaret() { var el = document.getElementById("editable"); var range = document.createRange(); var sel = window.getSelection(); range.setStart(el.childNodes[2], 5); range.collapse(true); sel.removeAllRanges(); sel.addRange(range); } Which APIs or add-in features? We are using Office.JS, see https://learn.microsoft.com/en-us/office/dev/add-ins/outlook/insert-data-in-the-body#insert-data-at-the-current-cursor-position We have asked this question https://github.com/OfficeDev/office-js-docs-pr/issues/5188 , but this feature isn't available. Can this feature be added? There is a more or less similar question here.
