PowerPoint JavaScript API: presentation.customXmlParts doesn't return the SharePoint document properties part (works in Word and Excel)

Question

PowerPoint JavaScript API: presentation.customXmlParts doesn't return the SharePoint document properties part (works in Word and Excel)

Andreas Davros 121

We have an Office task pane add-in that updates SharePoint library column values for the open document. It writes them into the SharePoint document properties custom XML part (root namespace http://schemas.microsoft.com/office/2006/metadata/properties, element documentManagement), and SharePoint copies them into the columns when the file is saved. This works in Word (document.customXmlParts, WordApi 1.4) and Excel (workbook.customXmlParts, ExcelApi 1.5).

In PowerPoint, presentation.customXmlParts (PowerPointApi 1.7) returns no parts for a presentation stored in the same library, although the file contains them.

If we add <p:custDataLst><p:custData r:id="rIdN"/></p:custDataLst> to ppt/presentation.xml, pointing at the existing relationship to the properties part, PowerPoint returns that part from presentation.customXmlParts. getXml and setXml then work, and SharePoint copies the values into the columns on save. So PowerPoint appears to expose only custom XML parts referenced from p:custDataLst, and SharePoint doesn't reference its properties part there.

Is it by design that PowerPoint.Presentation.customXmlParts only includes parts referenced from p:custDataLst? Is this documented anywhere?
Is there a supported way for a PowerPoint add-in to read and update the SharePoint document properties part, or the library column values, for the open presentation?
If not, is support planned, for example listing all package-level custom XML parts as Word and Excel do?

0 comments

1 answer

Your answer

Answer 1

Roebe Ta 1,825 Independent Advisor

Hello @Andreas Davros ,

Thank you for the detailed investigation and for sharing your findings.

While reviewing Microsoft's documentations, I noticed that the descriptions for customXmlParts differ slightly across Office hosts:

Excel describes customXmlParts as the collection of custom XML parts contained by the workbook.
PowerPoint exposes Presentation.customXmlParts as the collection of custom XML parts in the presentation.

Based on the available documentation, it is not entirely clear whether <PowerPoint.Presentation>Presentation.customXmlParts</PowerPoint.Presentation> is intended to expose all package-level custom XML parts or only those that are considered part of the presentation model. The documentation also does not appear to explicitly address the SharePoint document properties XML part scenario that you described.

Given the thorough repro you have already provided, including the observation that the XML part becomes available after being referenced through p:custDataLst, I would recommend opening a discussion in the Github Office JavaScript API Discussions forum. This would allow the engineers there to review the behavior, clarify the expected functionality, and potentially improve the documentation if additional guidance is needed.

Note: This link is shared by community members for your convenience. It points to a third-party site that is not managed or verified by Microsoft. I can’t guarantee the quality, safety, or suitability of any content or software found there. Please review carefully and make sure you understand any potential risks before using it.

If you do open a GitHub issue, I would recommend including the repro steps you've provided here, particularly the observation that the XML part becomes accessible through presentation.customXmlParts after it is referenced via p:custDataLst, as that should help the engineers there investigate and provide guidance.

For reference, the following documentation may be helpful:

I hope this helps. Feel free to let me know if you need any further assistance.

Kind regards.

Andreas Davros 121 Reputation points

2026-11-02T13:19:40.5933333+00:00
Thanks. One more question, separate from the PowerPoint behavior: is updating the SharePoint document properties part from an Office add-in a supported way to update library column values?

What we rely on:

The part's format: the custom XML part with root namespace http://schemas.microsoft.com/office/2006/metadata/properties, described in [MS-OE376] Part 1 §15.2.4 and the Content Type Schemas section of [MS-OI29500].

SharePoint copying that part's values into the library columns when the file is saved. We found this documented only in the SharePoint 2010 developer docs ("XML Document Property Promotion and Demotion"), not for SharePoint Online.

Changing only the text of existing fields under documentManagement, matched by local name (the column's internal name). Each field's namespace and the rest of the part stay as SharePoint wrote them.

customXmlParts with getXml / setXml in Word and Excel.

We also observed, without finding documentation:

once the part exists, SharePoint uses it instead of custom document properties with the same names;

when a file contains two such parts, SharePoint uses the first one linked from the main document part.

Questions:

a. Is modifying this part from an add-in a supported scenario that will keep working in SharePoint Online and current Office clients? Or does it rely on implementation details that may change without notice?

b. If it isn't supported, what is the recommended way for an add-in to update library column values for the open document? Microsoft Graph PATCH /drives/{id}/items/{id}/listItem/fields returns 423 Locked while the document is open.
Roebe Ta 1,825 Reputation points Independent Advisor

2026-11-03T14:10:48.2566667+00:00
Thanks for your response.

Based on the documentation currently available to me, I have not found any Microsoft documentation for SharePoint Online or the current Office JavaScript API that explicitly states that modifying the SharePoint document properties custom XML part from an Office add-in is a supported contract for updating library column values.

Since your questions concern:

Long-term supportability of updating the document properties XML part.

SharePoint Online promotion/demotion behavior.

The recommended modern replacement, if any.

I would recommend posting these questions to the Office JavaScript API GitHub Discussions forum as well.

In particular, your observations about SharePoint preferring the document properties part over custom document properties, and selecting the first linked part when multiple such parts exist, are valuable implementation details. Clarification from the engineering team would help determine whether those behaviors are intentional and supported, or merely current implementation characteristics.

Given the impact on solution design and long-term compatibility, I believe an authoritative answer from the product team would be the most reliable guidance here.

Regards.