Feature Request: OfficeJS Enhancing Shortcuts and Conflict Resolution for Add-ins
We’ve encountered a few challenges while working with shortcuts in our add-in, particularly when it comes to detecting and handling conflicts. Here's a breakdown of the issues and some suggestions for improvement: 1.) Detecting Shortcut Conflicts: Currently, we can use the areShortcutsInUse method to check if a shortcut is already in use when users attempt to set a new shortcut. However, we’ve realized that this function doesn't provide enough context. Specifically, it doesn’t inform us where the conflict is coming from. Suggestion: It would be incredibly helpful for our users if we could provide more detailed information about the conflict. For example: Action ID: Identify which action (or command) the conflicting shortcut is associated with. Add-in Name: Identify which add-in (including third-party add-ins) is causing the conflict. This added clarity will not only improve the user experience by providing actionable information but will also help us troubleshoot issues more efficiently. 2.) Checking for Conflicts with Default Shortcuts: We’ve encountered an issue when attempting to check for conflicts with default shortcuts listed in a JSON file. Since the areShortcutsInUse method reports that all shortcuts are technically “in use” (even if they are only being set by our add-in), it doesn’t allow us to accurately detect conflicts between user-defined shortcuts and the defaults. Suggestion: We would like the ability to distinguish between default shortcuts defined in the manifest and those set by the user or other add-ins. This will allow us to check for true conflicts (i.e., when a user-defined shortcut is in conflict with another user-defined shortcut or an active add-in). 3.) Unassigning Shortcuts: Currently, there is no way to unassign a shortcut from an action; we cannot pass a null value to clear a shortcut. Passing an empty string results in the default shortcut being used, as defined in the JSON manifest. This limitation makes it difficult to fully customize shortcut management for users who wish to clear or reset shortcuts. Suggestion: It would be valuable to provide a method that allows us to unassign or reset a shortcut, either by passing a null value or a dedicated "clear" option. This flexibility will enable users to fully customize their shortcuts without being forced to keep default bindings when they don’t want them.
Word JS API - Simple events for content controls
Subscribing to events on content controls in large documents with many instances are not optimal. It is pretty bad that it is necessary to register events on every single content control. Please add new events on the document level. For example: context.document.onContentControlUpdated context.document.onContentControlDeleted context.document.onContentControlEntered context.document.onContentControlExited Let us just subscribe to these and get the event on all content controls in the document. Much simpler and more effecient The existing event context.document.onContentControlAdded works very well. Also, remember to trigger the onContentControlUpdated event on any change to the contents and/or metadata.
Improving Excel Add-in API failures when in CellEditMode
Hello Microsoft Add-in team! I'm developing an Excel Add-In and have some suggestions relating to Excel.ErrorCodes.invalidOperationInCellEditMode. I'm finding that having the Excel Add-In APIs all either delay execution or throw the CellEditMode error while the user is in cell edit mode is making for a bad user experience in my Add-in. For example, at launch, my Add-In TaskPane needs to check the workbook CustomXML for metadata specific to my Add-In. But (if I'm not mistaken) I can't do that if the user is in cell edit mode. It seems I have to call the API, get a failure, then tell the user something like "The Add-In is waiting for you to finish editing your cell" and try again with { delayForCellEdit: true }. It's messy. So my suggestions are three, supposing CellEdit errors are in some cases necessary: 1.) Can we make it so that not *every* API call is blocked when in CellEdit mode? For example, why should reading/writing CustomXML be blocked because of cell editing? Is the error being thrown unnecessarily in some cases? 2.) Can we add a new "addHandlerAsync" event for CellEditMode enter/exit, to allow a TaskPane to disable buttons that aren't going to work while the user is in CellEdit mode? Disabling such buttons (with explanation, of course) could make for a better TaskPane user experience than having the user clicking a button and getting an error. (I do realize the error could still happen, as change events seem to fire on a delay, but they might at least happen less frequently!) (For example, in my Word Add-In, I am enabling/disabling buttons based on user's content selection, and the experience seems to be nice, even with the slight delay.) 3.) Can we add another callback param to "Excel.run({ delayForCellEdit: true }, ...)" so the developer can know that their API calls will be delayed and the user can be prompted to exit CellEditMode? (That might clean up me having to try, catch and then retry with delay?) I'm sure you've thought about all this more than I have, but these are the issues I'm running into. Thanks for your time and keep up the good work!
Ability to Assign Custom Properties or Unique IDs to Individual Cells
Summary I'd like to request support for assigning custom metadata — such as unique IDs or arbitrary key-value pairs — directly to individual cells in Excel using the Office.js API. Why This Matters Currently, developers must rely on workarounds like named ranges, hidden metadata sheets, or cell notes to simulate per-cell identifiers. These approaches are either limited, fragile, or not scalable for large applications. Native support for cell-level metadata would unlock powerful use cases: Dynamic form builders Cell-level validation engines Workflow tracking Data lineage and audit trails Integration with external systems via stable cell references Proposed API Concept range.customProperties.add("id", "cell_001"); const id = range.customProperties.getItem("id").value; Or even: range.metadata = { id: "cell_001", status: "approved", validator: "admin" }; Benefits Eliminates reliance on fragile naming conventions Enables scalable, structured metadata management Improves developer experience and app robustness Alternatives Considered Named ranges: limited and global scope Notes/comments: visible to users, not structured Hidden metadata sheets: hard to maintain Custom XML parts: complex and not cell-specific Request Please consider adding support for cell-level metadata or custom properties in a future version of Office.js. Even a lightweight key-value store per cell would be a game-changer.
Retrieve the existing contents of a cell that invokes a function
Define the problem My Excel add-in has custom functions which call external APIs. These API calls are invoking complex models running in the cloud which can sometimes take minutes to complete and therefore return data to Excel. My users build large workbooks with potentially thousands of these functions. Often the user makes a change in their workbook which triggers all of these calculations again even though there's no change in the input data. An example would be insertion of a row or column. This causes huge pain for the end user. Solution Microsoft to update the Office JS API so that when a function is invoked it can check the contents of the cell that invoked the function. I seem to remember this was possible in the old COM add-ins but it's not possible in the Office JS add-ins. Why does this help My custom functions store both the API request and response in the data card (Excel.EntityCellValue) format. Since I effectively store the original API request in the cell, if the cell gets inadvertently invoked I can check the arguments of the functions (the input data) against the original API request and if nothing has changed then I can return the original API response stored in the cell. This is like cancelling a function but being able to return the original data rather than anything new. Alternatives I can implement caching, e.g. using IndexedDB, but that's not the ideal solution. The ideal is the above.Office.js API — Open OneDrive Files in Current Word/PPT Instance
Currently, Office.js does not provide an API to directly open a OneDrive (or SharePoint Online) file in the current Word/PPT desktop instance. For add-ins that integrate with external systems, this creates a significant limitation. Users often need to: Access Word/PPT documents stored in OneDrive/SharePoint directly from an add-in. Ensure the file opens seamlessly in the same Word/PPT session, without forcing them to manually download or open a new instance. Why this is important Improves user workflow and productivity. Essential for add-ins that sync or integrate with cloud storage and external systems. Avoids user confusion from multiple Word windows or manual file handling. Requested capability An Office.js API such as: Office.context.document.openFileFromUrl(fileUrl, options); where fileUrl is a OneDrive/SharePoint URL and options could specify whether to open in the current instance or a new one. This would align Office.js capabilities more closely with real-world workflows and reduce friction for both developers and end-users.
