Enhanced Document Control/Protection APIs in Office.js for Word Add-ins
We are developing a Word add-in using Office.js and JavaScript APIs. Our use case requires advanced document control features, which are currently challenging to achieve within the existing Office.js framework. Here’s our feature request: Proposed Functionality: Based on the defined custom properties on a document via add-ins, provide APIs/commands/hooks to disable or override Word's default 'Save,' 'Save As,' and 'Share' options to prevent users from saving or sharing the document locally. Introduce additional APIs for implementing custom protection mechanisms within the add-in. Current Challenges: Achieving this functionality appears possible through VSTO add-ins, but they are not compatible with Office.js solutions. VSTO/.NET commands require complex workarounds, such as creating a separate .NET server to communicate with Office.js, which adds development complexity and affects efficiency. Request: We would greatly appreciate the introduction of built-in, efficient APIs in Office.js to handle document protection and control scenarios seamlessly without relying on external frameworks or services. This would significantly enhance the capability of modern web-based add-ins and improve the development experience for Word add-in developers.
Identify multiple embedded instance of the same add-in in a file as one
Summary By default, when a file is opened in Excel with a JS add-in installed and then saved, the JS add-in is automatically embedded in the file. In the current design all embedded add-ins will be attempted to load when the file is opened even if the embedded add-ins are the same. As a result, when these files are shared with other users who already have the same JS add-in installed with a different version or deployment method, Excel displays two instances of the same add-in in the tabs, or occasionally shows an error in the task pane if the version it is embedded is an older one. We first became aware of this issue when a user reported seeing our JS add-in appear twice in the ribbon, which led to confusion. Upon inspecting the affected file’s XML web extensions, we identified two versions of the same add-in embedded: one deployed via OMEX and another via exCatalog. After further investigation and filing a ticket with Microsoft Support, it was confirmed that this behavior is by design under the current implementation. Why This Matters While we understand that this behavior is expected by design, it remains problematic for users—it can cause confusion and potential issues with custom functions or with the add-in itself. Also, it is not clear for As of the moment there are no easy workaround for users to remove the duplicate/additional instance of the same JS add-in embedded in the file, this will also need to be done for every file that is suffering from this issue (has multiple instance of the same add-in embedded in the file w/ different version/deployment method). Proposed Change/s Update current design to be able to identify if the embedded adds-in is the same through checking and comparing a unique id so even if they have different deployment/version tags it will not be loaded/attempted to be loaded in the task pane. Alternatives Considered Provide an option in Officejs API to prevent embedding/referencing add-in in a file Benefits Prevents users from seeing the same add-in appear twice in the file Eliminate propagating errors in the task pane from trying to render the same add-in with the old version tag [Alternative considered] Allow users/dev to be able to control which add-in gets embedded in the file
German Excel Support Pages – Surprised by Multiple Errors
Dear Microsoft Community, While studying the financial functions in Excel, I was surprised to notice that several German-language support pages contain errors — such as incorrect translations, English function names, non-working example formulas, wrong results, and some spelling mistakes. I enjoy working with this material and would be happy to assist in reviewing and correcting these pages on a paid, freelance basis. I realize this may not be the exact place for such an offer, so I would greatly appreciate it if someone could point me to the right contact person or department at Microsoft. Thank you very much for your help! TheoBring the new font options to Word for iPad
The https://learn.microsoft.com/en-us/javascript/api/requirement-sets/word/word-api-desktop-1.3-requirement-set?view=word-js-desktop-1.3 has introduced various useful options in the Font class, like: AllCaps Borders Kerning Scaling Underline color And many more. However, it's a pity that the WordApiDesktop 1.3 is supported only on Windows and macOS, while the previous two WordApiDesktop were also supported on iPadOS. While I would love to see all the new additions of the WordApiDesktop 1.3 to the iPad version, at least adding the new font properties would be really useful to improve text customization.
Add-in Manifest: allow wildcards for app domains
Currently all trusted app domains must be listed fully qualified in the manifest, e.g. <AppDomain>https://customer1.acme-eu.com</AppDomain> <AppDomain>https://customer2.acme-eu.com</AppDomain> <AppDomain>https://customer3.acme-us.com</AppDomain> <AppDomain>https://customer4.acme-us.com</AppDomain> Our company has several root domains for their customer tenants. In the example above acme-eu.com and acme-us.com. But as these customer tenant URLs (e.g. https://customer2.acme-eu.com) are sensitive data we can not put them in our delivered add-in manifest because all other customers would have the chance to see them. Currently our customers need to use the O365CentralizedAddInDeployment PowerShell command to configure additional domains before using our add-in which is extremely error prone and sometimes just not working. Many hours of support needs to be invested to get the configuration fixed. For example after every change in the configuration all users needs to manually clear their add-in cache in Excel. Having wildcards in the manifest would enormously help us and our customers: <AppDomain>https://*.acme-eu.com</AppDomain> <AppDomain>https://*.acme-us.com</AppDomain> During add-in submission Microsoft can validate that the used domains are trustful.
Set the file name for newly created the Excel file - Excel.createWorkbook()
Unable to set the file name for the newly created Excel file. I don't see any info on how to set the name for the Excel.createWorkbook() function which only accepts a base64 xlsx payload. The file opens up with a name called Book 1.PowerPoint add-in: hide / show slides
I am trying to add a sideload add-in doing some automation in PowerPoint. I couldn't find a command or property in the PowerPoint office add-in to hide/show slides, but I desperately need this functionality! I currently have to switch to a VBA script for this. However, I can't create a product that combines JavaScript and VBA. Thanks, Florian
Tags can't be exported / imported for slides using .exportBase64().
As can be seen in https://github.com/OfficeDev/office-js/issues/5989 https://github.com/OfficeDev/office-js/issues/6104 Tags on Powerpoint Slides/Shapes/Presentation currently are not exported or imported when running exportBase64 on a slide, essentially killing a very large part of the functionality that they would otherwise enable. It would be great if this could be added soon 🙏.
Feature Request: Add error/rejection support to Office.onReady() for network/dependency failures
Description Currently, when Office.js loads but one of its dependent resources (such as office_strings.js) fails to load due to network issues or blocking, the Office.onReady() promise never resolves or rejects. This leaves developers without a reliable way to detect missing dependencies. Instead of relying on timeouts or log messages, it would be very helpful if Office.onReady() provided an error callback or rejection in these scenarios. Why this matters: Helps developers handle production failures gracefully. Avoids arbitrary timeouts/workarounds to detect missing dependencies. Provides parity with modern async practices where promises resolve or reject deterministically. Enables better telemetry/analytics by explicitly knowing why initialization failed. Suggested Approach: If a required dependency fails to load, Office.onReady() should reject with an error describing the missing dependency. Alternatively, provide an event/callback (e.g., Office.onError) that developers can subscribe to. Example: Office.onReady() .then(info => { console.log("Office.js initialized:", info); }) .catch(err => { console.error("Office.js failed to initialize:", err); // custom fallback handling }); Impact: This would improve developer experience significantly and make add-ins more resilient in real-world network environments.Limitation with Static AppDomain Entries in Office Add-in Manifest
As outlined in the [Microsoft documentation](https://learn.microsoft.com/en-us/javascript/api/manifest/appdomain), trusted domains must be explicitly declared in the Office Add-in manifest using the <AppDomain> element. A trusted domain allows: - Pages, routes, or other resources in that domain to be opened directly in the root task pane on desktop Office platforms (note: this does not apply to Office on the web or dialog APIs). - Pages in that domain to make Office.js API calls from IFrames within the add-in. We are currently developing a first-party native Excel Add-in as part of a strategic partnership. However, our architecture requires support for customer-specific subdomains, such as: ``` <AppDomain>https://customer1.company.com</AppDomain> <AppDomain>https://customer2.company.com</AppDomain> <AppDomain>https://customer3.company.com</AppDomain> <AppDomain>https://customer4.company.com</AppDomain> ``` This list is dynamically growing, making it infeasible to maintain a static list of subdomains in the manifest. Each manifest update would require re-submission through AppSource, creating significant operational overhead and slowing down delivery. Because of this limitation, we’re forced to distribute customer-specific manifests and rely on M365 tenant admins to install the add-in manually—introducing friction and reducing discoverability for users. We propose enabling wildcard support for <AppDomain> entries in the manifest, e.g.: ``` <AppDomain>https://*.company.com</AppDomain> ``` This would allow all subdomains under company.com to be trusted without requiring individual enumeration, simplifying deployment and scaling while preserving security. This limitation has been highlighted and highly upvoted by the developer community in the following feature requests: - https://techcommunity.microsoft.com/idea/microsoft365developerplatform/add-in-manifest-allow-wildcards-for-app-domains/4162573 - https://techcommunity.microsoft.com/idea/microsoft365developerplatform/support-wildcards-for-appdomains-in-office-add-in-manifests-to-support-sub-domai/2312326