Share via

How to map Word custom document properties to SharePoint multi-select columns and keep uploaded files read-only?

COSANO, Luis 0 Reputation points
2026-04-15T06:39:13.2566667+00:00

Hello,

I am working on the integration of a Word template with SharePoint.

The template, configured with VBA macros, allows users to fill in different fields in several languages. In addition, independently from the selected language, it also populates a set of custom document properties.

These Word custom properties are mapped to columns in a SharePoint document library, so that when the file is uploaded or saved into the library, the metadata is filled automatically.

However, I am facing the following issues and design constraints:

  1. SharePoint multi-select fields do not correctly interpret the values sent from Word. For example, if in a Word custom property I store value1, value2, SharePoint interprets it as a single value instead of two separate selections.

I have tried using different separators in the Word property, such as:

, ; ;#

but the result is always the same.

After upload, I would like the files to become read-only, and the SharePoint fields to be non-editable. The reason is that I consider reverse synchronization to be too complex; in other words, if metadata is modified directly in SharePoint, I would then need those changes to be reflected back into both the Word document fields and the custom document properties.

Additional constraint: some SharePoint choice or multi-choice fields may have up to five language variants. However, in SharePoint, for simplification purposes, I have only used English values. Because of this, I do not see reverse synchronization from SharePoint back to Word as a viable option, since there is no complete one-to-one multilingual mapping.

My questions are:

  • Is there any supported way for SharePoint to correctly parse multiple values coming from a Word custom property into a multi-select column?
  • Is this scenario officially supported, or are Word custom properties only reliable for single-value SharePoint columns?
  • What would be the recommended architecture for this scenario?
  • Is there a recommended way to make uploaded documents read-only and prevent metadata editing in the library, while still preserving the initial automatic mapping?

Thank you very much

Microsoft 365 and Office | SharePoint | Development
0 comments

3 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Steven-N 25,305 Reputation points Microsoft External Staff Moderator
    2026-04-15T07:19:03.75+00:00

    Hi COSANO, Luis

    I have conducted some research base on your description, and the following information might help

    1/ Is there any supported way for SharePoint to correctly parse multiple values coming from a Word custom property into a multi-select column?

    My answer is NO. Word custom document properties are single value by design (string, number, date, or boolean). The property promotion pipeline extracts values from document properties and writes them to matching library columns according to this document, but it has no logic to parse a delimited string into multiple selections. None of the separators you tested (, ; ;#) are interpreted as multi-value delimiters at upload time.

    2/ Is this scenario officially supported, or are Word custom properties only reliable for single-value SharePoint columns?

    From my research, although single-value column mapping is supported and reliable. Multi-value column population through property promotion is not supported. The built-in promotion mechanism is not designed for complex field types, and multi-value choice columns must be populated through a separate channel after upload.

    Link information: Word -> SharePoint: Limit of Custom Document Properties in Word

    3/ What would be the recommended architecture for this scenario?

    In this context, you can use a two-phase approach:

    In Word, store multi-value metadata as a delimited string (; recommended) in the custom property such as single-value properties continue to promote automatically.

    After upload, a Power Automate flow triggered on "When a file is created or modified" reads the promoted string, splits it, and writes the array to the multi-value column. The multi-choice column must be supplied with an array in the format: [{ "Value": "Choice1" }, { "Value": "Choice2" }]

    To avoid reprocessing, add a boolean column and skip items where it is already true.

    For more information:

    https://sharepains.com/2019/04/01/update-a-multi-select-choice-power-automate/

    https://tachytelic.net/2023/03/power-automate-update-sharepoint-fields/

    Note: This information is provided as a convenience to you. These sites are not controlled by Microsoft, and Microsoft cannot make any representations regarding the quality, safety, or suitability of any software or information found there. Please ensure that you fully understand the risks before using any suggestions from the above link.

    4/ Is there a recommended way to make uploaded documents read-only and prevent metadata editing in the library, while still preserving the initial automatic mapping?

    From my perspective view, with this requirement, one option is to extend the same Power Automate flow to break permission inheritance on the item after processing. The REST call to break inheritance is: /_api/web/lists/getByTitle('[LIST]')/items([ID])/breakroleinheritance(copyRoleAssignments=true,clearSubscopes=true)

    Then remove Contribute/Edit permissions and assign Read. Users with only Read access cannot edit library metadata from the UI.

    Link information: SharePoint Online: Break Inheritance And Set List Item-Level Permissions with Power Automate

    Disclaimer: The approach above involves breaking SharePoint permission inheritance at the item level. Evaluate carefully before applying it in production and kindly consult your SharePoint administrator or IT governance team before implementing permission changes at scale. The information here is provided for reference only.

    Hope my answer will help you.

    If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".   

    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

    Was this answer helpful?

    1 person found this answer helpful.
  2. COSANO, Luis 0 Reputation points
    2026-04-15T06:47:47.18+00:00

    So, your answer is: Although Microsoft presents Word and SharePoint as integrated products, the documented integration appears to support mainly single-value metadata scenarios, not complex SharePoint field types such as multi-select columns.

    Was this answer helpful?

    0 comments

  3. AI answer

    2026-04-15T06:39:47.3066667+00:00

    The available information only covers how Word document properties and SharePoint columns integrate in general and how to control templates and read-only behavior; it does not describe any supported mechanism for parsing multi‑value data from a single Word property into a SharePoint multi‑select column, nor does it document multi‑value encoding formats for such mappings.

    From the documented behavior:

    • Word can surface and bind SharePoint properties (including metadata columns) into the document via the Document Information Panel and Quick Parts / Document Property fields. This is described for standard properties and external data columns, and is effectively single‑value per property.
    • SharePoint content types and metadata are exposed to Word as properties that can be inserted anywhere in the document. Changes to the property on the server are reflected in all inserted instances in Word, but this is still described in a single‑value context.
    • External data columns can be mapped into Word content controls via a library template so that values selected in Word are stored both in the document and as SharePoint column values when the document is saved back to the library.

    Within this scope, the following can be stated based on the context:

    1. There is no documented support for SharePoint automatically parsing multiple logical values from a single Word custom property into a multi‑select column using delimiters such as ,, ;, or ;#. The documented integration examples treat each mapped property as a single value.
    2. The documented and supported scenarios focus on one‑to‑one mappings between a Word property/content control and a single SharePoint column value (including external data columns). Multi‑select semantics or delimiter formats for multi‑choice fields are not described, so only single‑value mappings can be considered officially covered by the provided documentation.
    3. For architecture, the documented pattern is:
      • Define the metadata (columns/content types) in SharePoint.
      • Configure a document library template and open it in Word.
      • Insert the SharePoint properties (or external data columns) into the document using Quick Parts → Document Property or content controls.
      • Let users create new documents from that template via the library so that values entered in Word are stored both in the document and in the library columns when saved.
      • If more advanced logic is needed (conditional sections, additional fields, or AI‑assisted field detection), use the structured document generation features and manage the template from SharePoint, then fine‑tune in Word and publish back.
      This pattern assumes single‑value metadata per field and does not document multi‑value encoding or multilingual mapping logic.
    4. To keep uploaded documents read‑only and prevent metadata editing while preserving the initial automatic mapping, the context shows two relevant levers:
      • Use a document library template so that metadata is populated when the document is created and saved from Word (the mapping happens at creation time).
      • After that, manage access at the SharePoint/OneDrive/Teams level to make documents read‑only. The documentation points to making a document read‑only when stored on SharePoint/OneDrive/Teams, which is the supported way to prevent further edits once the initial mapping is complete.
      Additionally, SharePoint library settings such as checkout requirements, validation, and draft item security can affect whether synchronized files are editable or read‑only in clients, but those are described in the context of why files open read‑only rather than as a deliberate design pattern for this scenario.

    Because the provided documentation does not describe:

    • Any delimiter or encoding scheme for mapping multiple values from a single Word property into a SharePoint multi‑select field, or
    • Any multilingual mapping behavior between Word fields and SharePoint choice values,

    only single‑value mappings and standard read‑only controls at the library/document level can be treated as supported based on this context.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.