Add Method to Create Hyperlinks in PowerPoint JavaScript API
I am writing to request the addition of a method in the PowerPoint JavaScript API that allows developers to programmatically convert text into hyperlinks. Currently, this functionality is available in the Word JavaScript API, where the Range.hyperlink property can be used to set a hyperlink on a range of text. However, a similar capability does not exist in the PowerPoint JavaScript API. At present, the only ways to create hyperlinks in PowerPoint are through the user interface or by using VSTO add-ins. These methods are not ideal for developers who wish to automate the process within web and Mac add-ins. Implementing a method to set hyperlinks on text within the PowerPoint JavaScript API would greatly enhance its functionality and bring it closer to parity with the Word JavaScript API. This addition would be beneficial for developers seeking to create more robust and feature-rich PowerPoint add-ins. Thank you for considering this feature request. I believe it would be a valuable enhancement to the Office.js library and look forward to any updates on this matter. Sincerely, Simon Breslav
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
Gracefully handle unavailability of Office.js
The reliance on Office.js (and its dependencies) delivered from the network proves to be challenging in some scenarios. While ideally the platform would support full offline use, I'm hopeful that there are some incremental improvements that could be made to address some of our challenges in the shorter term. As an example, our add-in hooks into Outlook's OnMessageSend, which inherently puts it on the critical path of the user experience when sending emails. In scenarios where the user's network is slow or unreliable, or in an event of an Azure CDN outage that makes Office.js unavailable or slow to be delivered, the user experiences a long wait while Office.js is loaded on message send. I should highlight that Outlook attributes this delay to the add-in: "Add-in X is taking longer than expected". I'd like to propose that the platform gives the add-in more control over the user experience in these cases. What this would look like for our OnMessageSend add-in is that the add-in would execute some code outside of the event handler (before Office.js finishes loading) to start a timer, and if the loading phase exceeds a timeout value defined in the add-in code then the add-in would instruct Outlook to conclude the processing of the event (similarly to how event.completed() is invoked inside an event handler). That last part would require some interface with Outlook that is available even if Office.js hasn't been fully loaded.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
From New Outlook (client) launch URL in system browser
From an Outlook Addin running in New Outlook (client) we need to be able to open a third party website in the system browser. This is currently only possible on New Outlook on web. Only method currently available is to open a dialog, but the third party site does not fit very well there. I am rewriting an old VSTO addin to be able to run in New Outlook. The addin opens a third party web site that I do not control. I need to be able to replicate the behavior of the VSTO addin which calls ShellExecute WIN32 API to handle the URL.
Ability 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.
Add a Range API for Outlook add-ins
Word add-ins provide the Word.Range API, which allows precise manipulation of document content (selection, insertion, replacement, formatting). Outlook add-ins currently lack an equivalent API, making fine-grained interaction with the message body difficult or impossible. We propose adding a Range-like API for Outlook add-ins to enable: • Access to the current selection in the message body • Insert or replace text at a specific position This would significantly improve advanced authoring, productivity, and AI-assisted scenarios in Outlook. Example (conceptual) const range = Outlook.context.mailbox.item.getSelectedRange(); range.insertText("Hello world", Outlook.InsertLocation.replace); Reference Word Range API : https://learn.microsoft.com/en-us/javascript/api/word/word.range?view=word-js-preview
[Office.js Add-in] Add functionality to set LinkToPrevious to Word Header/Footer sections
Hi there, Please add functionality to get/set the "Link To Previous" to header/footer sections I see that it is possible in Office VBA Add-in but not in Office.js see link: https://docs.microsoft.com/en-us/office/vba/api/Word.HeaderFooter.LinkToPrevious Thanks!Expose full gradient fill definitions for shapes in the PowerPoint JavaScript API (read and write)
Context I am building a PowerPoint add-in that enforces consistent corporate design by applying predefined styles from a centrally managed custom library (for example, gradient presets for specific object types). The add-in must be able to inspect existing shapes to detect deviations from the defined style and to apply the correct gradient styling back to shapes. This differs from PowerPoint’s out-of-the-box “Format Painter” / “copy-paste format” workflows because the style definitions are stored uniformly in the add-in and can be applied across any presentation without requiring that a “reference shape” with the desired formatting exists in the current deck. Pain The current PowerPoint JavaScript API does not provide access to gradient details on shape fills. While a shape’s fill type may indicate a gradient, there is no API to: Read gradient definition details (linear/path type, direction/angle, stops, stop positions, per-stop colors, per-stop transparency, theme color references, etc.) Write or update gradient definitions (set angle, add/remove stops, set stop positions, set colors, set alpha/transparency per stop) As a result, add-ins cannot implement reliable style sets and enforce application. The only workaround is OOXML parsing and round-tripping slides, which is complex, error-prone, and not feasible for real-time formatting workflows. Example Imagine a design system defines a “Primary Accent Gradient” used across shapes in many presentations: Linear gradient at 45 degrees Three stops at 0%, 60%, 100% Specific colors and transparency per stop A user selects multiple shapes and triggers “Apply Primary Accent Gradient” from the add-in’s style library. With the current API: The add-in cannot read the existing gradient definition to determine whether shapes comply with the design system. The add-in cannot set the target gradient definition precisely (stops, positions, direction, transparency). The add-in cannot store and reapply gradient styles consistently across presentations because gradients cannot be expressed as a reusable, structured object via the API. Request Please extend the PowerPoint JavaScript API to support full gradient manipulation for shape fills, both reading and writing, similar in capability to what is available in the PowerPoint UI. A possible API surface (illustrative) could include: Read gradient definitions on a shape fill, for example: shape.fill.gradient (nullable; available if shape.fill.type === Gradient) shape.fill.gradient.type (linear/path) shape.fill.gradient.angle (for linear gradients) shape.fill.gradient.stops: GradientStop[] with: position (0..1 or 0..100) color (RGB/hex and optionally theme reference) transparency or alpha Write/apply gradient definitions, for example: shape.fill.setGradient(gradient: GradientFill) shape.fill.gradient.stops.add(...), remove(...), clear() shape.fill.gradient.angle = ... Optional convenience methods for consistent styling scenarios, for example: shape.fill.applyFillStyle(fillStyleId: string) or a similar concept if Microsoft plans broader style primitives. This would enable add-ins to: Audit slides for gradient compliance Apply centrally stored gradient presets across any presentation Enforce consistent visual design at scale without relying on manual format copying or a reference shape present in the deck This feature would improve the viability of professional formatting add-ins for PowerPoint.Expose geometric shape type as a readable property for existing shapes in PowerPoint JavaScript API
Context I am building a PowerPoint add-in focused on slide auditing and efficient object management. A key capability is to identify and batch-manage geometric shapes on a slide (for example, select all hexagons, delete all ovals, or convert all rectangles into callouts). The current PowerPoint JavaScript API supports setting a geometric shape type when creating a new shape, but it does not allow reading that geometric shape type from existing shapes. Reference: PowerPoint.GeometricShapeType (Preview) documentation: https://learn.microsoft.com/en-us/javascript/api/powerpoint/powerpoint.geometricshapetype?view=powerpoint-js-preview Pain It is not possible to determine the underlying geometric preset (rectangle, oval, hexagon, etc.) for an existing shape via Office.js. The API provides shape.type (for example, geometricShape), but not the actual GeometricShapeType value for shapes that already exist on the slide or are selected by the user. As a result, common productivity workflows cannot be implemented reliably and efficiently, including: Select all hexagons on a slide Delete all ovals across selected slides Convert all rectangles into crosses Create consistent formatting rules based on shape geometry (for example, apply specific outlines to all diamonds) Example Imagine a slide containing multiple geometric shapes: rectangles, ovals, and hexagons. A user selects the slide and wants the add-in to: find all ovals and delete them, and find all rectangles and convert them to a cross shape. With the current API, the add-in can only see that these objects are geometric shapes (shape.type === geometricShape). It cannot read whether an individual geometric shape is a rectangle, oval, hexagon, etc. The only workaround is to parse the underlying OOXML or apply unreliable heuristics, which is complex, error-prone, and not feasible for real-time interactions. Request Please expose the geometric preset type for existing shapes as a readable property in the PowerPoint JavaScript API. Concretely, one of the following (or similar) options would solve the problem: Add a readable property on Shape for geometric shapes, for example: shape.geometricShapeType: PowerPoint.GeometricShapeType (read-only, available when shape.type === geometricShape) Ensure it is loadable on collections, for example: shapes.load("items/type,items/geometricShapeType") Optionally provide convenience filtering APIs for performance and usability, for example: slide.shapes.getByGeometricShapeType(PowerPoint.GeometricShapeType.hexagon) or a filter method on collections This would enable robust batch operations (select, delete, replace/transform) and significantly improve add-in capabilities for slide auditing and formatting enforcement without requiring OOXML parsing.
