A team builds a Word template in development, tests it against real records, gets sign-off from the business, and goes looking for the button that sends it to production. There isn't one. No export option in the template list, no solution component, nothing in Package Deployer that touches it. The template that took two days to build and test has to be built again, from nothing, in the next environment.
Microsoft's own documentation is direct about why. Word and Excel templates sit in two Dataverse tables, DocumentTemplate for organisation-wide templates and PersonalDocumentTemplate for the ones a user builds against a specific record. Both store the template file as Dataverse binary data. Microsoft's guidance on using Word templates in Dynamics 365 states plainly that these are not solution-aware components and cannot be added to a solution, and that environment-to-environment migration for them is not supported. A template downloaded from one environment can only be used within that same environment. There is no documented first-party tool or method for carrying a DocumentTemplate or PersonalDocumentTemplate record from dev to test to production. The documented requirement is manual recreation, template by template, in every environment that needs one.
Dynamics 365 Word templates are not solution-aware
Excel templates get the same treatment. They live in the same DocumentTemplate table as Word templates, and Microsoft's documentation on analysing data with Excel templates confirms they are not solution-aware and that environment-to-environment migration for them is not currently supported either. This is not a Word-specific quirk. Anything built through the native Dynamics 365 document template feature, in either format, sits outside the solution framework entirely.
There's a second layer that changes how much manual work this actually is. Templates created from the admin center are organisation templates, stored in DocumentTemplate and available to every user. Templates created from within a record are personal, stored in PersonalDocumentTemplate, and visible only to the person who built them. Both tables support security roles that control read and write access separately, so an admin can lock down who touches what. That split leaves a visibility gap. A personal template someone built against their own record isn't something that shows up in any organisation-wide template list. Plan a go-live around promoting organisation templates and the personal ones scattered across individual users' lists still won't move, and nobody notices until one of those users opens production looking for a template that never got rebuilt.
For the fuller set of restrictions on this native feature, including which Word versions are supported for building templates and which content control types are safe to use, see our piece on Dynamics 365 Word template limits.
What the Configuration Migration Tool and Package Deployer actually cover
The Configuration Migration Tool is Microsoft's answer to moving configuration and test data across environments, and it does that job well for the tables it supports. It runs off an XML schema file that defines which entities, attributes, relationships and uniqueness conditions to export, and it packages the result into a zip file containing both the schema and the data. None of that applies to document templates. Microsoft's documentation on managing configuration data does not list DocumentTemplate or PersonalDocumentTemplate among the supported entities. The same page states outright that the Calendar entity and the Image column are excluded, and templates sit in that same category of absence rather than partial support. The tool also moves records, not table schema, so even for the entities it does support, what travels is data, not structure.
Package Deployer sits a level above the Configuration Migration Tool. It bundles one or more Dataverse solution files together with configuration data exports from that tool into a single deployable package, which is useful for standing up a full environment in one pass. But it inherits whatever the Configuration Migration Tool can't do. If that tool doesn't touch DocumentTemplate or PersonalDocumentTemplate, Package Deployer can't reach them either. Neither tool has a path for document templates as solution components, because the underlying tables were never built to travel that way.
The SharePoint route and what breaks on import
Because the native tables won't move, a fair number of teams route their templates through SharePoint or OneDrive instead and drive generation with Power Automate. The Word Online (Business) connector works with Word files stored in OneDrive for Business, SharePoint Online sites, and Office 365 Groups. The Populate a Microsoft Word template action reads from a .docx file with content controls configured inside it, and only .docx, not the older .dotx template format, a separate detail that trips people up on its own.
The part that costs someone a day sits in how flows carry that file reference. When a flow using this connector gets exported inside a solution, the path to the SharePoint or OneDrive file is stored directly inside the flow definition. Import that solution into a target environment where the site structure, library name, or folder path doesn't match exactly, and the flow now points at a file that isn't there. The solution import itself succeeds without complaint. Nothing breaks until someone actually runs the flow, which by then is usually well after go-live, and the fix means opening the flow and manually repointing every action that references the file. A related failure shows up in desktop flows too, where working against Word files in a OneDrive or SharePoint synced folder can produce file not found errors, because of a documented incompatibility between those synced folders and Word's COM automation.
Practitioners deal with the hard-coded path problem by parameterising the file reference with environment variables or connection references rather than typing a fixed path into the action. That's a workaround people use, not something Microsoft documents as an official solution for the template reference itself, and it's worth treating it as exactly that, a fix built by people who hit the same wall, rather than a supported pattern with a Microsoft article behind it.
Some approaches avoid this failure mode altogether by having the template ship as part of the solution from the start, so there's no separate SharePoint reference to break in transit. Where that's the direction being weighed, an approach where the template ships inside the solution removes the environment-specific file path from the equation entirely.
Environment variables and connection references
Environment variables are Microsoft's documented pattern for exactly this kind of problem, values that need to differ between dev, test and production without touching the underlying flow or app logic. They're solution components, so they travel with a solution on import, and the value itself can be changed at import time to match the target environment. They support a Data source type for Dataverse, SharePoint and SQL Server connectors, and a Text type that can hold a file path for use inside canvas apps and cloud flows. An environment variable is limited to 2,000 characters.
One piece of Microsoft's guidance cuts against the instinct to use them here directly. Microsoft recommends against storing a literal SharePoint template file path inside an environment variable, and points instead toward the connector's own native path selection or manual entry inside the action. The supported pattern is environment variables for values that differ by environment, and the connector's built-in path picker for the file itself. Forcing a raw file path into an environment variable because it's convenient is where teams drift off the documented path while still technically using a documented feature.
Connection references sit next to environment variables as the other solution component doing real work here. A connection reference is a solution component that points at a connection for a specific connector, and solution-aware canvas apps and flows bind to the reference rather than to the connection directly. On import, a connection gets provided for every connection reference in the solution, which is what lets a flow come back on automatically in the new environment. Both the Word Online (Business) connector and the OneDrive connector use connection references when packaged in a solution. In practice, someone often still has to go in after import and re-create or re-authenticate the connection in the target environment before the flow will run. Custom connectors add one more step, since they need to be imported in their own solution ahead of any connection reference or flow that depends on them.
Versioning, template limits and what to do about it
There is no documented Microsoft guidance for versioning an individual Dataverse document template, Word or Excel. Dataverse doesn't keep version history for records in DocumentTemplate or PersonalDocumentTemplate the way it does for other components. Power Automate flows do get version history, retained for 12 months, but that covers the flow definition, not the template file sitting inside it. Storing the template in SharePoint instead of Dataverse brings SharePoint's own document versioning along with it, at the cost of everything above about how that file reference behaves once it's wired into a flow and moved through a solution.
Changing a template has consequences for documents already generated from the old one. A generated document is a static snapshot. It doesn't update when the template changes afterward. Regenerating from an updated template can overwrite manual edits or comments someone made on a previously generated document, and Microsoft does not support a way to refresh an already-generated Word document without risking exactly that loss.
On sheer volume, there's no documented cap on how many Word or Excel templates can exist in a single environment. The one number that does show up, a 95 MB solution size limit, doesn't actually constrain templates directly, since they can't be added to a solution in the first place.
None of this is unmanageable, but the checklist has to be built by hand, because no tool builds it automatically. Keep a single tracked list of every template that exists in production, organisation and personal, with an owner attached to each personal one, since PersonalDocumentTemplate records won't show up in any admin view. Rebuild templates in the same order every time, dev first, then test, then production, and test document generation after each rebuild rather than assuming a template that worked in dev will behave the same once security roles and record data differ. If a flow is driving generation through SharePoint or OneDrive, check the connection reference and the file path inside the flow after every import, before anyone tries to run it, rather than waiting for a user to find the broken reference.