Simple Smooth Safe
Insight · Dynamics 365

Dynamics 365 Word template limitations

Where the out-of-the-box Word template actually stops — repeating tables, conditionals, XML mapping, related records, the first hundred rows — and why none of it is a setting you can flip.

By Duarte ClementePublished 2 September 20269 min read

The Word template feature in Dynamics 365 is genuinely useful, and for a one-page document built from one record it is the right tool: it is free, it ships in the box, and a business user can build one without a developer. This piece is about the point where that stops being true.

Most of what people search for here — "if condition not working", "repeating table not working", "only showing 100 rows" — is not a bug and not a setting hidden behind a support ticket. It is the feature working exactly as Microsoft documents it. The frustration comes from expecting a reporting engine and getting a mail-merge. The failures below are each checked against Microsoft Learn, and each one names what you can actually do about it.

XML mapping error / not working / update XML mapping

A Dynamics Word template is built in Word itself. You enable the Developer tab, open the XML Mapping Pane, pick the schema that starts with urn:microsoft-crm/document-template/, then right-click a field and Insert Content Control. That schema is the whole template. There is no live connection to Dataverse — it is a snapshot of the entity and the relationships you ticked when you downloaded the file.

Two things bite here. First, if a field or a related entity is missing from the pane, there is nothing to "update" — you have to go back, download a fresh template with the right relationship selected, and rebuild. The mapping is not something you edit after the fact. Second, Microsoft's own documentation carries a warning that inserting any content control other than Plain Text or Picture, or making a textual change to a control (including the capitalisation AutoCorrect applies for you), can freeze Word hard enough to need Task Manager. The documented mitigation is to turn AutoCorrect off before you start. That is the state of the authoring surface.

Related records only appear if you selected that relationship on the download dialog before you ever opened Word — the 1:N, N:1 or N:N relationships you tick there decide what exists in the XML schema. Miss it, and the contacts, lines or activities you expected simply are not in the pane, and there is no way to add them without downloading a new template.

Even when the relationship is present, you get no control over which records come back or in what order. Microsoft documents that lists "might not appear in the same order" as the app shows them, because records come out in the order they were created. There is no sort, and — see the next two sections — no filter and no ceiling you can raise. For a summary block that is fine. For an invoice whose lines must be grouped and ordered, it is a wall.

If-condition example / not working

Searches for a Dynamics Word template "if condition" come up empty because the feature does not exist. Content controls are plain-text bindings to a field — they print whatever value is there. There is no documented syntax for "if the status is Won, show this paragraph", no conditional sections, no hide-when-empty. A control bound to a blank field prints nothing; a control bound to a value prints the value; that is the entire logic model.

This is the limitation people hit hardest, because real documents are conditional: a clause that appears only for one contract type, a payment block that changes with currency, a signature line that depends on value. Native Word templates cannot express any of it. The usual workaround — maintaining a separate template per variation — multiplies the maintenance rather than solving the problem.

100 rows only

This one is documented, so it is worth stating precisely rather than as folklore. Microsoft's guidance is that, to keep documents downloading quickly, a template returns up to 100 related records for each relationship. Their own example: export an account template that lists contacts, and the document returns at most 100 of that account's contacts.

It is not a cap you can lift with a setting, and it is per relationship, not per document. If your record has more than a hundred related rows — line items, transactions, timesheet entries — the document is silently short and nothing tells the reader that rows were dropped. A silent truncation on a document you send to a client is a different class of problem from a slow one, and it is the reason volume documents outgrow this feature first.

Format a date field

There is no documented way to format a value inside a Word template. A content control is Plain Text, so a date arrives as the raw exported value and a number arrives unrounded and unseparated — you cannot ask for 31 December 2026, or two decimal places, or a thousands separator, from the template. Formatting the control in Word changes the font, not the value.

For anything customer-facing this matters more than it sounds. Dates and currency are exactly the fields a reader scrutinises, and "format the date" is not a job the native template was built to do. If the presentation of a value matters, it has to be shaped before it reaches the template, which native Word templates give you no hook to do.

Repeating table

Repeating is supported, and it is the feature most templates are really built around, so it is worth being exact about what it does. You put the fields for the repeating rows into a single table row, select that row, then in the XML Mapping Pane right-click the relationship and choose Repeating. On generation the row multiplies down the table.

The limits are structural. A repeating region is one table row bound to one relationship, so a layout that needs a header row per group, a subtotal line, or a table nested inside a repeating block is not something the mechanism expresses. Combine that with no sort, no filter and the 100-row behaviour above, and the repeating table handles the simple list it was designed for and falls over on anything with structure inside it. When people say the repeating table "isn't working", this shape mismatch is usually what they have run into.

Content control

The content control is the unit the whole feature is built from, and its constraints are the feature's constraints. Microsoft supports exactly two types in a Dynamics template: Plain Text and Picture. Inserting any other control type is listed as something that can destabilise Word, and so is editing the text of a control after you place it. Even the picture path has an edge: many entities have no EntityImage field out of the box, so putting a record's image into a template first means creating an image field on the entity and populating it.

So the control gives you a value or a picture, in place, with no formatting and no logic. That is a deliberately small surface. It is enough for a letter and not enough for a document that has to make decisions about its own content.

Rich text not working

A rich-text or multi-line field that holds HTML does not render as formatted content in a Word template, because the only text control available is Plain Text. What is worse is a documented export behaviour that turns this from "unformatted" into "wrong": certain characters — <, > and the non-breaking-space entity — are not supported in document export, and the text between them is removed. Since rich text is stored as HTML full of angle brackets, exporting a rich-text field can silently drop content, not merely strip its formatting.

If your notes, descriptions or terms live in a rich-text field, this is not a styling nuisance; it is a data-loss risk on the finished document. The native template has no supported path for rendering rich text as rich text.

There is no filtering. The related records you selected at download time come back whole, in creation order, up to a hundred per relationship — you cannot ask a repeating region for "only the open lines", "only this year's activities" or "only the primary contact". The template consumes whatever the relationship returns.

In practice teams reach for a workaround: build a database view or a rollup that pre-filters the rows, then point the template at that. It can work, but you have now moved the real logic out of the template and into the data model, and you are maintaining both. That is the tell that the document has outgrown the tool — the interesting part of the work is no longer happening in the template at all.

Dataverse Word template — create / not working

Two operational limits catch people last. Templates are environment-bound: Microsoft states that environment-to-environment migration of Word (and Excel) templates isn't supported, and a template only works in the environment where it was downloaded. So a template built and tested in a sandbox cannot simply be promoted to production the way a solution component can — it is rebuilt or re-uploaded per environment, outside your ALM.

And the authoring itself is particular: templates are created in specific desktop Word versions, macro-enabled documents aren't supported, and right-to-left languages have known formatting problems in the output. None of this makes Word templates bad. It makes them a document tool with a document tool's boundaries, and knowing the boundaries is the point.

What to do

Match the tool to the document rather than fighting the tool.

The test is not how the document looks today. It is whether the document has to make decisions — show this clause but not that one, group and total these lines, drop the rows that do not apply. A native Word template cannot make decisions. Once your document has to, you have left what the feature was built for, and the honest move is to change tools rather than to keep a wall of near-identical templates alive.