Apply DOCX Template generates schema-invalid OOXML — Word recovery dialog + all PDF actions fail

Documents
1

Hi Plumsail team and community,

We're hitting two related, reproducible issues with Apply DOCX Template (operationId FlowV1DocumentsJobsApplyDocxTemplatePost) in the Plumsail Documents Power Automate connector. Sharing here in case anyone else is seeing the same and to flag it for the dev team.

Issue 1: Generated DOCX is schema-invalid OOXML

Word opens any DOCX produced by Apply DOCX Template with the dialog:

Word found unreadable content. Do you want to recover the contents of this document? If you trust the source, click Yes.

Microsoft's official Open XML SDK Validator (DocumentFormat.OpenXml.Validation.OpenXmlValidator) reports 30+ schema violations on the same file. Unique error types:

  • <w:tblLook> carries firstRow, lastRow, firstColumn, lastColumn, noHBand, noVBand as namespaceless attributes — they must be in the w: namespace.
    • <w:document> root has Ignorable="w14 wp14" but does not declare xmlns:w14 / xmlns:wp14.
    • <w:tcBorders> contains <w:left> (rejected by strict OOXML — <w:start>/<w:end> expected).
    • Misplaced <w:pBdr> and <w:tcBorders> placement violations.
      These violations are present in fresh and historical files alike — going back at least a year. Newer Office builds appear stricter and now surface the recovery dialog where older builds silently auto-repaired.

Issue 2: All PDF actions fail with "file is broken"

Three separate operations in the connector return the same error when handed our DOCX (the same file Word eventually opens after recovery):

  • FlowV1DocumentsJobsApplyDocxTemplatePost with request/outputType = "PDF"
    • FlowV1DocumentsJobsDocx2PdfPost (Convert DOCX to PDF — deprecated)
    • FlowV1DocumentsJobsAny2PdfV2Post (Convert to PDF)
      Each returns:
HTTP 400
{
  "error": {
    "code": "ApplicationResultException",
    "message": "The file is broken: The file appears to be corrupt..."
  }
}

Microsoft's own PDF conversion (Graph /drives/{id}/items/{id}/content?format=pdf) ALSO rejects the same DOCX with OfficeConversion_ContentNotSupported, suggesting the upstream DOCX is the actual culprit, not your PDF engine alone. Once we round-trip the document through LibreOffice headless (which silently fixes the schema violations on save), all three PDF actions succeed.

Sample trace IDs (latest first)

  • D0265F42C379AB4AB252B
    • 42C979F4F09D24449A7EC
    • 166031192BE9BF48AD12A
    • 7BB77D1F1615F745BFBBE
    • D375A28E8D95EE4597979
      (All from Apr 29, UTC)

Reference to past similar case

This looks similar to Getting ApplicationResultException in Fill in PDF Form in power automate — Aleksandra confirmed it was a backend issue and the dev team fixed it without any user changes. May be a regression of the same kind.

Environment

  • Tenant: vicomplus541.onmicrosoft.com
    • Connector: shared_plumsail (Plumsail Documents)
    • Power Automate region: westeurope, runtime europe-002
    • Use case: WorkOrder service report flow producing both DOCX and PDF copies for engineers in our service business

Ask

  • Can the OOXML schema compliance of Apply DOCX Template output be fixed (tblLook namespace, Ignorable namespaces, tcBorders children)?
    • Once that is in, the PDF conversion actions should succeed too — could you confirm?
      For now we're using a LibreOffice-based workaround in front of the PDF actions, but it'd be great to retire that once Plumsail handles its own output cleanly. Even just confirming that schema-invalidity is the known root cause would help us decide whether to wait or keep the workaround.

Thanks!

2

Hi @Bow ,

Thank you very much for such a detailed and well-structured report. This is very helpful.

To investigate this issue further on our side, we’ll need a bit more information from your side:

  • A sample of the generated DOCX file (the one that triggers the Word recovery dialog)
  • Your Power Automate flow structure: what steps are used and in what order (screenshots would be perfect)
  • The input data (JSON) that you pass into the document generation action
  • If possible, the original template file as well

For security reasons, you’re welcome to send all of this directly to our support email (support@plumsail.com) instead of posting it publicly.

Additionally, could you please confirm the exact Plumsail Documents action name you are using in Power Automate?
We don’t have an action named “Apply DOCX Template” exactly, so it would be helpful to clarify which of the following actions your flow is using:
The list of actions in the Plumsail Documents connector for Power Automate

Once we have these details, we’ll be able to reproduce the behavior and continue the investigation.
Thank you again for your cooperation!

Best regards,
Aleksandra
Plumsail team

3

Hi Aleksandra,

Thanks for the quick response, and apologies for the action-name confusion.

The action we use is "Create document from DOCX template" (operationId FlowV1DocumentsJobsApplyDocxTemplatePost in the OpenAPI spec — that's the source of "Apply DOCX Template" wording in my original post).

Confirmed reproducing the same issue with both engine: Modern (default) and engine: Classic — output is structurally identical and Word still triggers the recovery dialog in both cases.

I'm sending you the full bundle (sample generated DOCX, original template, sanitized input JSON, flow definition export, validator output) directly to support@plumsail.com — referencing this thread.

Best,
Sabyr

4

Hi,

Thank you for the update and for sending all the details. We’ve received your ticket.

We’ll continue the investigation there, and once the issue is resolved, we’ll share a summary and the solution here as well for visibility.

Thank you for your cooperation!

Best regards,
Aleksandra
Plumsail team

5

Hi Aleksandra,

Huge thanks — you nailed the root cause perfectly. :clap:

You were absolutely right: the template itself was the problem. Once I round-tripped it through LibreOffice headless to clean up the schema (preserving all the {{var}:html} Plumsail markers), Word stopped showing the recovery dialog and Plumsail's own PDF actions started working as expected too — no "file is broken" anymore. Everything now flows directly through Create document from DOCX template + Convert to PDF without any external workaround.

Genuinely impressed by how quickly you identified that the inherited template structure was the culprit — we'd spent hours blaming the connector when the template was the source. Top-tier diagnostic work.

From our side this is fully resolved. The ticket can be closed. Thanks again for the patience, the clear ask for the repro bundle, and the spot-on analysis.

For anyone else finding this thread later: if your generated DOCX triggers Word's "unreadable content" recovery dialog and Plumsail PDF actions return ApplicationResultException: The file is broken — check whether your template itself triggers the recovery dialog when opened directly. If it does, the simplest fix is to round-trip it through LibreOffice (libreoffice --headless --convert-to docx) once; this normalizes the OOXML and resolves both issues downstream.

Best,
Sabyr