Auto-grant Sites.Selected access to the SP site created when provisioning a Microsoft 365 Group
When a site collection is created directly via POST /sites with the Sites.Create.All permission, the calling application is automatically granted Sites.Selected + FullControl on that new site collection — no extra step required (confirmed here: https://devblogs.microsoft.com/microsoft365dev/sharepoint-site-creation-in-microsoft-graph/). However, this auto-grant does not extend to the SharePoint site that gets provisioned automatically when a Microsoft 365 Group is created via POST /groups. An app that only holds Sites.Selected (not tenant-wide Sites.ReadWrite.All) can successfully create the group, but has no access to the group's backing site afterwards — even though it was the app itself that triggered the site's creation. The only current workaround is a manual follow-up call to POST /sites/{site-id}/permissions to grant the app write access to that site, which adds an extra step, an extra failure point, and potential race conditions (the backing site is not always immediately available/addressable right after group creation). Request: extend the existing Sites.Create.All → Sites.Selected auto-grant behavior to also cover the case where a site is provisioned indirectly, as a side effect of Microsoft 365 Group creation. If an app has the rights to create the group, it should be automatically granted Sites.Selected + write access to the site that gets created along with it — consistent with how direct site creation already works. This would let apps that follow least-privilege practice (Sites.Selected only, no Sites.ReadWrite.All) provision groups and immediately manage their sites in one atomic step, without a manual permission-grant call or having to poll/retry for the site to become available.
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.The Office JS range.formulas API should preserve the leading single quote.
We have an Excel add-in used in both Excel O365 Desktop and Excel O365 Web. Our add-in processes formulas in cells, including custom functions, and sometimes needs to remove prepended namespaces. The relevant code is: const range = context.workbook.getSelectedRange(); range.load("formulas"); await context.sync(); console.log('The range formulas', range.formulas); const newFormulas = range.formulas; range.formulas = newFormulas; Problem: Some users enter informational strings in cells that resemble formulas like '=AVERAGE([cell start]:[cell end]) To ensure excel treats these as plain text, they start the entry with a single quote ('). Excel correctly stores these as strings and does not throw any formula error. However, when we use the Office JS API to read and reapply these values, the leading single quote is stripped. The API returns: '=AVERAGE([cell start]:[cell end])' When we attempt to set this value back using range.formulas = newFormulas, excel throws the following error: RichApi.Error: The argument is invalid or missing or has an incorrect format. at new n (excel-web-16.00.js:25:328325) at i.processRequestExecutorResponseMessage (excel-web-16.00.js:25:393560) at excel-web-16.00.js:25:391621 The Office JS API does not preserve the leading single quote, so Excel interprets the value as a formula, which is invalid in this context. This behavior is inconsistent with Excel’s native handling, where the single quote ensures the value is treated as text.
Spill Override for Dynamic Arrays in Excel
Dynamic arrays in Excel currently prioritize existing cell content over new calculations, causing a #SPILL! error whenever an expansion path is obstructed. In professional financial modeling, this creates significant friction and introduces unnecessary risk. Examples of this issue can be found everywhere, and I want to offer a widespread one from the finance domain. Financial analysts frequently build time series that combine dynamic historical actuals with manually entered forecasts. As time progresses and new actuals are fetched - often via external data functions - the dynamic array must expand. Under the current logic, if a new data point reaches a cell containing a manual forecast, the entire historical range disappears and is replaced by an error. To prevent this, modelers are forced to manually shift forecast blocks or build complex formulas to stitch disparate data ranges together. These workarounds are time-consuming and prone to errors. The impact here is threefold: Maintenance overhead: Analysts must perform manual grid maintenance every time a data period closes. Model fragility: A single stray value or a manual forecast in the expansion path can break an entire dashboard, hiding valid data. Logic complexity: Users must resort to cumbersome workarounds to manage the boundary between dynamic and static data, making models harder to build, maintain and audit. I propose adding an explicit option to override default spill handling. This would introduce an operation that allows users to permit a dynamic array to overwrite existing grid content when a collision occurs, rather than forcing the standard #SPILL! error. The goal is to let users choose when a dynamic formula should take precedence over the existing data in that range.Extend Outlook Actionable Messages Admin Dashboard Report to support all provider scopes.
The Outlook Actionable admin dashboard report currently only covers Organization-scoped providers. Providers registered at other scopes are excluded, creating a visibility and governance gap for enterprise admins. Please extend this functionality to all available scopes as this would enable admins to maintain comprehensive audit trails and perform end to end lifecycle governance of Actionable Messages providers from a single interface.
Outlook Graph API- Add a Currently Selected Email call
Just like we have trackers like inbox counter, unread counter, and such, it would be nice to be able to have an invisible API action that would 1 select an email, 2 return a value to client of what selected email title/content is. Use case: I want to make a Macro to display my selected email in a zoomed in section of my screen/ a watch area I want to inflict API calls only on said email and I want confirmation of which email is now selected This provides a seamless invisible (to client) way for developers to implement API actions in their software/hardware. Right now I am side stepping this issue using Flag/unflag, but it is a messy solution and leaves a "Completed on X" residue on every email it touches , and I made an experimental way with clearflag function (is a little Shakey with excessive polls) , which is needed to flag/unflag, then clear flag every time your run a command, and it all has to run through a dedicated PowerShell to avoid overlaps of calls . All that can be avoided with this Just like like outlooks selects emails by default right now with most recent unread or or most recent in inbox , make it where a signed in account can select any email (at least in new outlook) by scrolling with arrows or clicking once on an email and viewing it from the side panel (even if its not marked as read) as long as they are hovering it, it sends an API call of what the user is hovering to MS servers and have that info available to be sent to an API call a to a dev so they can use to apply actions against said email (create a meeting from it, send a premade reply or any other API action specific to emails selected) ---- and make that invisible to users, and if worried about excessive server demand, making it an advanced option in outlook to be toggled by users when using applications that require it and make the applications themselves carry the burden of information the user they need to toggle said setting before starting to use their app , that way the option is limited to the population that uses it and is not making everyone constantly ping Microsoft servers with what email they are looking at.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 - Add intent‑based flow creation and context‑aware suggested actions.
I would like to suggest a more guided, intent‑driven experience when building flows in Power Automate. When a user starts a new automation, the designer could first prompt them to describe in natural language what they want to accomplish, then automatically propose an appropriate starter flow, trigger, and key actions based on that intent. At each subsequent step, instead of primarily listing all possible actions and connectors, the interface could provide a prominent “Suggested actions” section that is context‑aware and continuously updated according to the user’s goal and existing steps in the flow, similar to intelligent code suggestions in modern editors. This would accelerate flow creation, reduce the learning curve for new users, and help experienced users quickly discover the most relevant actions without manually searching through long action lists.Support for user tracking with insertfilefrombase64
We work in the Compliance space, that requires us to track users who made changes to a document. We also have an Add-in that utilizes insertfilefrombase64 method to insert/replace content in our documents. When we use this method, the user is getting tracked as "Unknown" thus failing to track the user who made such changes. Requesting that this be changed and updated to track the user. If the same was done manually, the change is reflected against the user. a relevant bug was raised which was marked as an dev enhancement request by the team. https://github.com/OfficeDev/office-js/issues/5472
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 Reference
