Microsoft 365 Developer Platform Ideas

Spill Override for Dynamic Arrays in Excel

akalyan — Mon, 08 Jun 2026 12:33:33 GMT

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.

Sraina — Mon, 08 Jun 2026 09:34:55 GMT

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

LeoPew — Mon, 08 Jun 2026 09:11:41 GMT

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.

Feature Request: Expose Theme Color RGB Values in Office.js API

Hokiefan00 — Fri, 05 Jun 2026 14:02:02 GMT

Title

Add API to retrieve resolved RGB/hex values for workbook theme colors

Summary

The Office.js API currently does not provide a method to retrieve the actual RGB or hex color values for theme colors applied in a workbook. When chart elements, shapes, or cells use theme-based fills (e.g., "Accent 1", "Accent 2"), developers can identify the theme color type but cannot programmatically resolve it to the actual color value.

Problem Statement

When automating chart formatting tasks, I need to:

Read the current fill color of a chart point (which uses theme colors)
Apply that same color to other points in the series

Current behavior: point.format.fill.getSolidColor() fails or returns undefined for theme-based colors. The API only exposes the abstract theme reference, not the resolved RGB value.

Impact: This prevents common automation scenarios such as:

Uniformly formatting chart data points across historical vs. forecast periods
Copying formatting between elements that use theme colors
Maintaining brand consistency when programmatically generating charts
Migrating or syncing formatting between workbooks with different themes

Proposed Solution

Add methods to expose resolved theme colors:

// Option 1: Query the theme directly const color = await context.workbook.theme.getColor("Accent1"); // Returns: "#4472C4" // Option 2: Resolve fill color regardless of source const resolvedColor = await point.format.fill.getResolvedColor(); // Returns: "#4472C4" (works for theme, solid, or automatic fills) // Option 3: Get full theme palette const palette = await context.workbook.theme.getColorPalette(); // Returns: { accent1: "#4472C4", accent2: "#ED7D31", ... }

Business Justification

Essential for enterprise automation of branded reports and dashboards
Enables consistent formatting across programmatically generated charts
Reduces manual formatting work for recurring financial/business reports

Affected API Area

Excel.ChartPoint.format.fill
Excel.ChartSeries.format.fill
Excel.Workbook (new theme property)

Expose originalRecipients property for compose/reply scenarios

girtsegr — Mon, 01 Jun 2026 15:54:38 GMT

Context

When a user clicks on "reply" or "reply all" in Outlook, add-ins should be able to retrieve the original recipients (To, CC, BCC) of the mail item as they were set when the reply or reply all action was initiated, regardless of any user edits to the recipient list afterwards.

Currently, office-js returns an updated recipient array if the user quickly changes the recipients after clicking "reply" or "reply all". As a result, there is no way for an add-in to determine what the original recipients of the mail item were. This makes it difficult to compare and process recipient changes.

Steps to reproduce

User receives an email with recipients A, B, and C.
User clicks "Reply All".
Before sending, user deletes B and adds D to the recipients.
Office-js API only returns the new recipient array (A, C, D), with no way to access the original recipients (A, B, C).

This issue affects add-ins that need to compare the original recipients of an email to the recipients after user edits, for processing or compliance reasons. Having access to the original recipient list would make it possible to implement robust recipient management features. Currently, even if you store these recipients during onMessageCompose event, it is possible to have wrong data there if user changes recipients right away after clicking reply / reply all / forward.

Support application permissions (app‑only / Managed Identity) for Planner Task Chat Messages API

NS1066 — Thu, 14 May 2026 10:50:51 GMT

Request
Please add Application (app‑only) permission support for Planner task chat messages:

GET https://graph.microsoft.com/beta/planner/tasks/{task-id}/messages

Current limitation
This endpoint is currently delegated-only (works when signed in as a user) and does not work for Managed Identity / app‑only automation scenarios (e.g., Azure Automation Runbooks). This blocks unattended exports and reporting.

Why this matters (business impact)

We run scheduled Azure Automation Runbooks (Managed Identity) to export Planner data for governance and Power BI reporting.
The “new Planner” experience uses task chat messages as the primary comment mechanism, and these messages are required for audit/reporting.
Without app‑only access, organisations are forced into less secure patterns (service accounts, interactive token flows) that complicate compliance.

What we want (minimum viable)

Read-only app permission support to list messages (equivalent of “read task chat”).
Least-privileged permission option such as Tasks.Read.All for app-only (or a new narrower scope if preferred).
Standard access enforcement (only return messages for tasks/plans the app is allowed to read).

Why app-only is needed
Managed Identity is the recommended secure pattern for Azure-native automation. Requiring delegated auth prevents reliable unattended reporting at enterprise scale.

Many thanks

No programmatic way to pin the task pane for users

mikeyp88 — Tue, 05 May 2026 12:14:31 GMT

Your Environment

Platform: PC desktop, Mac, Office on the web
Host: Outlook
Office version number: All supported versions
Operating System: Windows, macOS

Expected behavior

The Office JS API should provide a programmatic mechanism to pin the task pane on behalf of the user — for example, via a manifest setting or a runtime API call — so that the task pane remains open and pinned without requiring manual action from each user.

Current behavior

There is no programmatic way to pin the task pane for users. Users must pin it manually via the UI. This results in an inconsistent experience, particularly for enterprise deployments where we need to ensure the add-in remains accessible without relying on individual user action.

Context

We need the task pane to remain pinned for all users automatically upon install or first launch. The current lack of a programmatic pin mechanism creates friction and support overhead, as users frequently close the task pane and do not know how to re-pin it. We are looking for either an existing API we may have missed, or confirmation that this is a platform gap so we can raise a feature request through the appropriate channel.

Outlook Monarch: Add Inline preview of attachments

sstko — Mon, 04 May 2026 12:52:21 GMT

Classic Outlook shows attachment preview right in the message window instead of opening a whole new window. This is more convenient as it allows the user to just quickly check the attachment and switch to another message right away instead of having to close the whole window to get into the main interface again.

Allow Outlook add-ins to detect when user is composing during read-mode activation

dina-smokeball — Mon, 04 May 2026 06:49:04 GMT

When an Outlook add-in is opened via the message action bar while a user is composing a reply, the add-in loads in read mode. However, the add-in has no way to detect that the user is actively composing, which prevents any compose-specific functionality from working correctly.

Steps to Reproduce

Open Outlook and select an email message
Click Reply to start composing a reply
Click an add-in button from the message action bar
The add-in loads with the /read URL route
The add-in cannot determine whether the user is composing or just reading

Expected Behavior

The add-in should have a way to detect that a compose window is open so it can adapt its behavior or redirect to the appropriate compose mode.

Actual Behavior

The add-in loads in read mode with no API or mechanism to detect that the user is composing. The URL alone (/read) is insufficient to determine the actual user context.

Root Cause

Currently, there is no Office.js API that allows a read-mode add-in to detect whether a compose window is open for the current message. The manifest also does not provide context-aware routing capabilities.

Requested Solution

Please provide one or more of the following:

An Office.js API that allows read-mode add-ins to detect if a compose window is active for the current message
A way for the manifest to route action bar buttons contextually (to /compose if composing, /read if reading)
Additional context information passed to the add-in so it knows which entry point was used and the actual user context

Without this, any add-in that supports both read and compose functionality cannot provide a consistent user experience when opened from the message action bar during compose.

Access to Equations via Word JavaScript API

Jakob76 — Tue, 21 Apr 2026 06:09:16 GMT

Currently, the Word JavaScript API does not provide access to equations (built using Word’s equation editor / Office Math). This limits the ability to programmatically interact with structured mathematical content in documents.

It would be highly valuable if the API allowed developers to:

Enumerate equations within a document or range
Access the underlying equation structure or markup (e.g., Office Math / OMML)
Read and modify equation content
Convert equations to a linear or plain-text representation

Providing access to equations would significantly improve document automation, analysis, and interoperability with other systems that rely on mathematical content.

Thank you for considering this enhancement.

Add Workbook.calculate() to avoid recalculating all open workbooks

stephanecoze — Thu, 16 Apr 2026 15:43:11 GMT

Today, the Office.js API exposes Excel.Application.calculate(calculationType), but it recalculates all currently opened workbooks in Excel. This becomes a performance and UX problem when users have multiple large workbooks open and an add-in needs to trigger calculation only for the workbook it’s running in.

Request: Please add a workbook-scoped calculate API that recalculates only the active workbook, while reusing the existing Excel.CalculationType enum (recalculate, full, fullRebuild).

Example API shape (one option):

await Excel.run(async (context) => {

context.workbook.calculate(Excel.CalculationType.recalculate);

await context.sync();

});

This would preserve the current semantics of Excel.CalculationType while avoiding unintended recalculation of unrelated open workbooks (the current Application.calculate behavior).

Preserve Add-in signature HTML on Outlook for iOS across all clients

dsantaras — Mon, 13 Apr 2026 13:36:12 GMT

Summary

When an Office Add-in inserts HTML into a message on Outlook for iOS (for example, an email signature), Outlook for iOS rewrites the inline CSS at the point the content is added to the message body. The rewritten CSS uses modern shorthand and the currentcolor keyword, which classic Outlook on Windows (the Word based rendering engine) does not render correctly. The result is that recipients opening the message in classic Outlook on Windows see missing or incorrect styling, most visibly missing border colors on signature elements.

The same message renders correctly when opened in Outlook on the web, new Outlook for Windows, Outlook for iOS, and Outlook for Android. Only classic Outlook on Windows is affected, because only the Word rendering engine fails to interpret the rewritten CSS.

Who this affects

Any organisation using a third party signature Add-in (or any Add-in that injects styled HTML) on Outlook for iOS, whose recipients include users of classic Outlook on Windows. This is a large population: classic Outlook on Windows is still the default client in many enterprises.

We are raising this on behalf of a significant number of affected customers who currently have no workaround.

What we observed

We insert this HTML into the message via the Add-in:

Outlook for iOS rewrites it, before it is committed to the message body, to:

Two behaviours are problematic:

The individual border-top, border-right, border-bottom, border-left declarations are merged into border-width, border-style, and border-color shorthand.
The merged border-color uses the currentcolor keyword for the three unset sides.

Classic Outlook on Windows does not honor currentcolor reliably in this context, and its handling of this particular shorthand combination drops or miscalculates the actual colored side. The colored border the sender intended is not displayed to the recipient.

Why this is a problem specifically for Add-ins

Authors of Office Add-ins cannot control what the host client does to HTML after body.setSignatureAsync, body.setAsync, or equivalent insertion APIs are called. The HTML we provide is valid, and it renders correctly on every other Outlook surface. The rewrite is happening inside Outlook for iOS, silently, and we have no API to opt out of it.

Reproduction

Build a simple Outlook Add-in that inserts the HTML snippet above into a new mail message using the standard Office JS body insertion APIs.
Send the message from Outlook for iOS (tested on iOS 18.3.2, Outlook for iOS 4.2513.1).
Open the sent item in Outlook on the web or Outlook for iOS: the yellow left border renders correctly.
Open the sent item in classic Outlook on Windows: the left border color is missing.

Prior report

This was previously reported against Office JS on GitHub: https://github.com/OfficeDev/office-js/issues/6521. The response was that the issue will not be fixed in the short term, and the recommendation was to raise a Tech Community item so the team can gauge demand. That is what this post is for.

What we are asking for

Ideally one of the following:

Stop Outlook for iOS rewriting inline CSS that was supplied by an Add-in through the supported insertion APIs. Pass the author's HTML through unchanged, or
If normalisation has to happen, avoid emitting currentcolor and avoid collapsing per side border properties into shorthand in ways that known Outlook rendering engines cannot interpret, or
Publish a documented, supported HTML and CSS subset that is guaranteed to round trip across all Outlook clients (including the Word rendering engine in classic Outlook on Windows), so Add-in authors can target it deliberately.

A way to get the character of bullet points in PowerPoint

Artur_Hellmann — Fri, 03 Apr 2026 01:42:15 GMT

The BulletFormat got updated, which is nice, but there is one disatvantage still:

When resetting a text of a shape completely, and the shape prior to the change, had squares as bullet points, the bullet points in the new text are set as disks.

So there are multiple ways to fix this, the last one is the optimal way that should be implemented:

The shape should have some "default" and keep the last bulletpoints that were set for each level
When setting bullet points, the shapes placeholder settings are used for this

Or the only right solution:
There should be a way to read the current type (square, circle, arrow, whatever) from the textRange.paragraphFormat.bulletFormat so we can save it and reapply the right type to the new text.

Skip Undo Entries for silent Actions of Addins

joerg-sap — Tue, 31 Mar 2026 11:03:14 GMT

Would it be possible to implement a Excel.run option to hide undo entries e.g supressUndoEntry?
Would be very helpful to set only wanted steps.

E.g users adds a table => refreshes => only one undo entry for resetting it.
I know we can group it but only in a single excel run not when using multiple.

i also like the idea of

https://techcommunity.microsoft.com/idea/microsoft365developerplatform/add-ability-to-label-the-actions-office-js-takes-on-the-document-in-the-undo-lis/4491484
for giving it atleast good names.

Ability to dynamically change ribbon button at runtime

schoong — Fri, 27 Mar 2026 20:15:28 GMT

Our ribbon button actions are awkward! We need the ability to interact with them more dynamically at runtime. Ideas:

Change Office.Ribbon.RequestUpdate() so that it can change a ribbon button's label at runtime, like the "Protect Sheet"/"Unprotect Sheet" button in the Review tab.
Give us the option to create toggle buttons in the manifest and in contextual tabs, like Excel's native "Filter" button in the Data tab, or the "Bold" button.
Change Office.Ribbon.RequestUpdate() so that it can remove a ribbon button, or change its icon, at runtime

Ability to disable Copilot Agent / Edit functionality on a sheet + Copilot events

PurpleMacha25 — Tue, 17 Mar 2026 23:38:18 GMT

We developed an Excel addon which intercepts certain Excel events - sorting of Excel tables, editing cells, etc. on special add-on managed sheets.

This functionality is broken when Copilot Agent/Edit starts modifying the sheet.

Would it be possible to disable Copilot Agent/Edit mode on particular sheets in full and to provide rich API to intercept Copilot's actions?

Ability to determine which cells are currently being viewed by the user

jcofds — Mon, 16 Mar 2026 13:16:33 GMT

Summary
We did tests on the frontend with our streaming formulas and we were able to confirm that having multiple streaming cells can lead to performance issues on the frontend i.e. unresponsive / glitchy user interface. This can also possibly result to the updating of values slower than the expected rate.

Why This Matters
Our users are expected to work on large spreadsheets containing more than 50,000 streaming cells (potentially more for some users)
Having the capability to determine which cells are viewed by the users will open the possibilities for us to optimize the streaming values. We can make changes to our add-in wherein only the cells being viewed by the users are automatically updated instead of everything.

Proposed Change/s

Add capability to determine which cells are being viewed by the user

Benefits
Having this capability will prevent the scenario wherein the frontend will be not as responsive when dealing with multiple streaming values

Feature Request - Add intent‑based flow creation and context‑aware suggested actions.

SajedaSultana — Wed, 11 Mar 2026 05:33:38 GMT

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.

Get selected chart element in Excel JS API

schoong — Thu, 05 Mar 2026 15:22:21 GMT

We need to read the data point when a user clicks on one of the parts of a bar chart or pie chart. Something like getSelectedChartElement() that points to the underlying cell range where the data point resides. Or a Chart event whenever a chart element is selected.

Copilot prompt amount information in Graph API

florisklaver — Tue, 03 Mar 2026 07:24:31 GMT

Can we include the number of prompts submitted by users with an M365 Copilot license through the Graph API? And split these out in where the prompts were submitted (Teams, Word, Excel, Chat, etc)?

This is a better marker than the usage activity date that we can currently work with. This shouldn't be too difficult as in the M365 Admin Center you already provide this information in the usage details.

Hope this is an easy inclusion as using the AI API is not recommended as it gives too much details about prompts for certain third party implementations.