Microsoft 365 Developer Platform Ideas

Show "Loading add-in" before the task pane web app is available

xTNTx333 — Fri, 10 Jul 2026 07:33:34 GMT

Product

Office.js / Outlook Classic (Task Pane Add-ins)

Problem Description

When a task pane add-in is opened in Outlook Classic, there can be a significant delay before the add-in's web application is displayed. During this phase, users often see a blank or empty task pane without any indication that the add-in is still loading.

Based on our observations, this delay frequently occurs before the add-in page itself is loaded and before any JavaScript code can be executed. The startup time appears to be heavily influenced by the underlying Chromium/WebView network initialization and page-loading process.

As add-in developers, we currently have no opportunity to provide feedback to the user during this early loading phase because the web application has not yet started executing.

User Impact

A blank task pane creates the impression that:

Outlook has frozen.
The add-in has crashed.
The add-in failed to load.
The user needs to close and reopen the add-in.

This leads to confusion, unnecessary support requests, and a poor user experience, especially in environments with slow network conditions, security software, proxy servers, or delayed WebView initialization.

Proposed Enhancement

Provide a native Outlook-hosted loading screen that is displayed immediately when the task pane is opened and remains visible until the add-in page has started loading successfully.

Example messages:

"Preparing add-in..."
"Loading add-in..."
"Initializing add-in environment..."

The loading screen could optionally include:

A progress indicator or spinner.
Diagnostic information for troubleshooting.
A timeout message if loading exceeds a configurable threshold.

Alternative Proposal

Expose an API that allows developers to define static HTML content that Outlook can display before the actual add-in page is loaded.

Since displaying simple HTML content is possible without waiting for the complete network stack and WebView page initialization, this would allow developers to provide immediate visual feedback while the Chromium/WebView infrastructure is still preparing the add-in.

Benefits

Improved user experience.
Reduced perception of application hangs.
Fewer support tickets related to slow add-in startup.
Better transparency during WebView initialization.
Improved reliability perception for Office Add-ins in enterprise environments.

Environment

Outlook Classic for Windows
Office.js Task Pane Add-ins
Chromium-based WebView runtime

The issue is most noticeable in environments where WebView initialization or network-related startup operations are delayed.

Add Microsoft Graph APIs for SharePoint Online list views

vleocmach — Wed, 08 Jul 2026 10:14:47 GMT

Microsoft Graph currently provides APIs for SharePoint sites, lists, columns, and list items, but it does not expose SharePoint list views. This creates a limitation for our application that need to read data related to a specific SharePoint list view, not necessarily the entire underlying list.

Please add Microsoft Graph support to read, create, update, delete SharePoint list views and get items scoped by the view.

Thanks in advance to the team

The Office JS range.formulas API should preserve the leading single quote.

Panthers_12345678Sudo — Tue, 07 Jul 2026 10:49:57 GMT

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.

Provide an Official Offline Distribution Method for Office.js (Alternative to CDN)

Merficius — Mon, 06 Jul 2026 23:08:44 GMT

According to the Microsoft documentation on accessing the Office JavaScript API library (https://learn.microsoft.com/en-us/office/dev/add-ins/develop/understand-the-javascript-api-for-office#access-the-office-javascript-api-library), the only official way to include Office.js in Office Add-ins is to load it from the CDN. While this works well for most scenarios, it creates a significant limitation for organizations that operate in offline or highly restricted network environments where external CDNs are not accessible.

Previously, the microsoft/office-js npm package (https://www.npmjs.com/package/%40microsoft/office-js) allowed developers to bundle Office.js with their add-ins, making offline deployments possible. Since this package has been deprecated, there is no longer an officially supported way to distribute Office.js in these environments.

I would like to request one of the following:

Bring back an officially supported npm package for Office.js.
Provide another supported mechanism for bundling or self-hosting Office.js in offline environments.
Publish official guidance for deploying Office Add-ins in air-gapped or disconnected networks.

Supporting offline deployments would enable organizations with strict security requirements—such as government agencies, defense organizations, healthcare providers, and enterprises with isolated networks—to continue developing and deploying Office Add-ins using supported Microsoft solutions.

This would greatly improve the developer experience and make the Microsoft 365 Office Add-ins platform accessible to a broader range of enterprise customers.

Native staged/canary rollout for Office Add-in manifests (Centralized Deployment/Integrated Apps)

harshitgoyal97 — Wed, 01 Jul 2026 07:05:40 GMT

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.

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 Jan 2026 known issue — 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 (docs).
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 (docs), 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).

Add application (app-only) permission support to the M365 Copilot agents

DanofToken — Tue, 23 Jun 2026 12:14:31 GMT

The beta endpoint GET /beta/copilot/admin/catalog/packages currently supports delegated permissions only - app-only (client credentials / service principal) calls are rejected with 403 "Access is denied to the requested resource". Note that CopilotPackages.Read.All is already grantable as an application role, but the service refuses app-only auth. Please enable app-only support for this permission so the agent catalog can be read by a background service without an interactive user.

Why this matters: we need to continuously inventory the Microsoft 365 Copilot agents deployed in a tenant for security and governance - tracking which agents exist, who published them, and how they change. We want to query this data from customer tenants, and it can only be performed properly using a service principal, not a user. Delegated-only auth forces an interactive session, making continuous collection impractical.

Request:

1. Enable app-only access for CopilotPackages.Read.All on /beta/copilot/admin/catalog/packages so it can be called with client credentials.

2. Clarify whether app-only access would carry the same Microsoft Agent 365 license requirement that applies today - and if so, whether a read-only inventory scenario can be supported without per-user licensing, since automated collection has no interactive user to license.

Partial / In-Place Updates for Performance-Sensitive Dynamic Arrays

akalyan — Fri, 12 Jun 2026 12:30:10 GMT

Currently, dynamic array formulas can only be evaluated as a single, indivisible block. When a data point changes within a large spilled table, Excel forces the entire array to recalculate and repaint. For performance-sensitive UDFs handling large datasets (e.g., simulations, massive lookups, or data feeds), this behavior introduces severe bottlenecks:

Massive CPU overhead: redundant calculations across thousands of unchanged cells.
UI lag: the screen visibly stutters or freezes during frequent updates.
Regression to workarounds: developers must abandon clean dynamic arrays and revert to legacy CSE arrays or complex VBA macros just to keep the workbook responsive.

I propose introducing support for partial or delta updates within dynamic array spill ranges. Excel's calculation engine should allow a UDF to target and update specific (row, column) indices in place, without marking the entire parent formula block as dirty or triggering a full-range UI repaint.

Why does it matter? Dynamic arrays are the future of Excel, but full-range recalculation is a major bottleneck for heavy data processing. This enhancement would unlock massive performance gains, keeping Excel highly competitive for large-scale, complex modeling.

Office.js API support for Power Query editing (enable Copilot & AI integration)

folotp — Wed, 10 Jun 2026 19:11:40 GMT

The Office.js API currently supports refreshing Power Query connections but provides no capability to read, create, edit, or delete Power Query (M code) definitions programmatically.

Use Case — AI Assistant Integration:
AI assistants (Microsoft Copilot, Claude, ChatGPT, etc.) interact with Excel via the Office.js API. Users increasingly expect these tools to help build and maintain Power Queries. Currently, AI assistants cannot:

Read existing M code to understand or explain data transformations
Create new Power Queries from natural language descriptions
Edit or debug problematic queries
Delete obsolete queries
Update connection strings, file paths, or query parameters programmatically

This represents a significant gap given Microsoft's investment in Copilot for Excel and the broader AI-assisted productivity vision.

Requested API Capabilities:

Read M code from existing queries
Create new queries programmatically
Edit M code for existing queries
Delete queries
Modify query parameters (file paths, connection strings)
Access query metadata (name, last refresh, error status, dependencies)

Impact:

Enables Copilot and third-party AI tools to fully assist with Power Query authoring
Democratizes Power Query by letting AI explain and write M code for non-technical users
Aligns with Microsoft's AI-first strategy for productivity tools

Platform: All platforms (Windows, Mac, Web)

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.

Microsoft 365 Developer Platform Ideas

Show "Loading add-in" before the task pane web app is available

Add Microsoft Graph APIs for SharePoint Online list views

The Office JS range.formulas API should preserve the leading single quote.

Provide an Official Offline Distribution Method for Office.js (Alternative to CDN)

Native staged/canary rollout for Office Add-in manifests (Centralized Deployment/Integrated Apps)

Summary

Category

Applies to

Motivation (real scenario)

What's missing (specifics)

What we've tried, and why it's insufficient

Requested capability

Precedent — Microsoft already ships this pattern elsewhere

Impact / who benefits

Environment

Questions for Microsoft

Add application (app-only) permission support to the M365 Copilot agents

Partial / In-Place Updates for Performance-Sensitive Dynamic Arrays

Office.js API support for Power Query editing (enable Copilot & AI integration)

Spill Override for Dynamic Arrays in Excel

Extend Outlook Actionable Messages Admin Dashboard Report to support all provider scopes.

Outlook Graph API- Add a Currently Selected Email call

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

Title

Summary

Problem Statement

Proposed Solution

Business Justification

Affected API Area

Expose originalRecipients property for compose/reply scenarios

Context

Steps to reproduce

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

No programmatic way to pin the task pane for users

Your Environment

Expected behavior

Current behavior

Context

Outlook Monarch: Add Inline preview of attachments

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

Access to Equations via Word JavaScript API

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

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