Calling VerseDocs from Power Automate

Every one of the 69 actions is an ordinary Dataverse Custom API, so there is no custom connector to install and no authentication to configure. One built-in step reaches all of them.

The one step every flow shares

  1. 1Add an action and search for the Microsoft Dataverse connector.
  2. 2Choose Perform an unbound action.
  3. 3Set Action Name to the action you want — vdocs_TemplateDocx, vdocs_PdfMerge, and so on. They appear in the dropdown once the solution is imported.
  4. 4Fill in the parameter fields the designer generates for that action.
  5. 5The outputs — OutFileContent, Result, Meta — become dynamic content for later steps.
That is the entire integration surface. Everything below is the parameter shape and a few worked patterns.

Parameter conventions

Every action reuses the same handful of parameter names, so once you know the pattern you can use any action without looking it up.

ParameterIn / OutShape
FileNameinPlain string. Optional; echoed back where relevant.
FileContentinBase64 of one input file. Power Automate’s File Content from a SharePoint, OneDrive or email trigger is already base64 — pass it straight through.
FilesinJSON array for multi-file actions: [{"name":"a.pdf","content":"<base64>"}].
DatainJSON string: the values to merge into a template, or a small payload object.
OptionsinJSON string: per-action settings.
TextinPlain UTF-8 text, not base64 — used by actions that work on short text rather than a file.
OutFileName
OutFileContent
OutContentType
outA single output file: its name, its base64 content, and its MIME type.
OutFilesoutJSON array when an action produces several files (vdocs_PdfSplit, vdocs_ZipExtract). Parse it, then use Apply to each.
ResultoutJSON string for actions that return data rather than a file. Parse it to reference individual fields.
MetaoutJSON string with details about the run, e.g. {"pages":3,"durationMs":840}. On PDF conversion it also names the rendering engine that ran.

Building the JSON parameters

Data and Options are JSON passed as a single string field. The reliable way to build one is a Compose action holding the JSON literal, with dynamic content dropped inside the string, then reference that Compose as the parameter value. Doing it inline invites the designer to mangle the quotes.

Using the output file

OutFileContent is base64 text. Most connector fields that accept a file — SharePoint and OneDrive “Create file”, Outlook attachments — are typed as binary, so wrap it:
base64ToBinary(outputs('...')?['body/OutFileContent'])
What you must not do is re-encode it — it is already base64, so never wrap it in base64(...) on top.
The Action Name dropdown of a Perform an unbound action step, listing vdocs_ actions alphabetically.
Every VerseDocs action appears here. Type vdocs to filter the list.
The same dropdown searched for the word VerseDocs, showing no values match your search.
Searching “VerseDocs” finds nothing — the actions are named by their schema prefix. Search vdocs.
A Perform an unbound action step with vdocs_TemplateFromRow chosen and an Advanced parameters control reading Showing 0 of 3.
Parameters stay hidden until you click Show all. This catches nearly everyone once.

Worked example: invoice PDF, emailed

The flagship pattern. Render a Word template straight to PDF and send it.

  1. 1Get the template file. From SharePoint, OneDrive, or a vdocs_template row.
  2. 2Compose the data as JSON.
  3. 3Perform an unbound actionvdocs_TemplateDocx, with FileContent = the template, Data = your Compose, and Options asking for PDF.
  4. 4Send an email, attaching base64ToBinary(...OutFileContent) with the name from OutFileName.
Data
{
  "customer": { "name": "Contoso Ltd", "city": "Seattle" },
  "invoiceNumber": "INV-1042",
  "total": 1250.00,
  "lines": [
    { "item": "Consulting", "qty": 10, "price": 100.00 },
    { "item": "Support",    "qty": 1,  "price": 250.00 }
  ]
}
Options
{
  "outputFormat": "pdf",
  "culture": "en-GB",
  "onMissing": "error"
}
One call renders and converts. There is no separate conversion step, no OneDrive round trip and nothing to configure — drop "outputFormat": "pdf" and you get a real PDF back.

Archival PDFs (PDF/A)

Add pdfConformance alongside outputFormat to produce an archival PDF — fonts embedded, colour device-independent, nothing referenced from outside the file. This is what records-retention and government archival requirements ask for.

Options
{
  "outputFormat": "pdf",
  "pdfConformance": "PDF/A-2b"
}
LevelUse when
PDF/A-1bThe most widely mandated, and the most restrictive. Choose this if a requirement just says “PDF/A”.
PDF/A-2bAdds transparency, layers and JPEG2000. A good default for modern documents.
PDF/A-3bAs A-2b, but allows arbitrary file attachments inside the PDF.

Spelling is forgiving — PDF/A-1b, pdfa1b and pdf_a_1_b all mean the same thing. An unrecognised value is an error rather than a silent downgrade to an ordinary PDF, because the dangerous outcome here is believing you have an archival file when you do not.

pdfConformance works the same way when generating from a Dataverse recordvdocs_TemplateFromRow, vdocs_GenerateAndAttach and vdocs_TemplateBatch. Note that batch asks for PDF via batchOutput rather than outputFormat, but takes pdfConformance alongside it unchanged.

Only the b (“basic”) levels are offered. The matching a levels additionally require full accessibility tagging, which depends on your template being authored with real heading styles, table headers and alt text — something VerseDocs cannot verify on your behalf. An unverifiable conformance claim is worse than no claim for exactly the buyers who ask for one.
PDF/A requires a licensed environment. Unlicensed output carries a trial watermark, and stamping a watermark into an archival PDF breaks the conformance it claims. Rather than return a file that says it is archival and is not, the call fails with EDITION_REQUIRED.

PDF/A also uses only the primary conversion engine, so a conformance request never falls back to an engine that would produce an ordinary PDF instead.

Worked example: straight from a Dataverse row

When the data already lives in Dataverse, do not assemble JSON by hand. Give vdocs_TemplateFromRow a template and a row id, and it resolves the template’s binding against that record — related records included.

  • Data names the template and the target row.
  • Everything in Template Syntax §7 applies: formatted values by default, _raw when you want the underlying one, related tables as arrays.
  • Use vdocs_GenerateAndAttach instead if you want the result attached to the record’s timeline in the same call — it is what the Generate document button uses.
The unbound action step with item/TemplateId, item/Options set to an output format of pdf, and item/RowId all filled in.
Three inputs and you have a PDF. Note the item/ prefix the Dataverse connector adds to every parameter name — the Action Reference lists them without it.

Worked example: many rows at once

vdocs_TemplateBatch generates for many records in one call. Name the rows explicitly with RowIds, or let it select them with FetchXML in Options. When both are supplied, RowIds wins.

Mind the two-minute ceiling. Every action must finish inside the Dataverse plug-in timeout, and a batch is one action. For large runs, chunk the work — select a month at a time, or loop in the flow — rather than asking for everything in a single call. See Limits.

Worked example: a barcode in a document

  1. 1vdocs_BarcodeGenerate with Data carrying the payload — an order number, a serial, a URL — and Options naming the symbology.
  2. 2Pass the returned image into vdocs_TemplateDocx as a named image in Options.images.
  3. 3Place {{image:barcode width=40mm}} in the template where it should appear.
Barcode Options
{ "type": "qr", "format": "png", "margin": 10 }
qr, code128 and ean13 are supported, as PNG or SVG. EAN‑13 requires a 12 or 13 digit payload and rejects anything else rather than producing an unscannable image. vdocs_BarcodeRead decodes in the other direction, detecting the symbology automatically.

Digitally signing a PDF

vdocs_PdfSign applies a cryptographic signature to a PDF using a certificate you supply. The signature proves two things to anyone who opens the document: that it has not changed since it was signed, and who signed it.

The private key never leaves your tenant. Signing happens inside your own Dataverse environment. Cloud document services that offer signing require you to upload the key to them — which for many organisations is the whole reason signing never got approved.
Data — the certificate
{
  "pfx": "<base64 of a .pfx/.p12 file, including its private key>",
  "password": "..."
}
Options — all optional
{
  "reason": "Approved by finance",
  "location": "London, UK",
  "contactInfo": "finance@contoso.example",
  "fieldName": "FinanceApproval"
}
  • Sign more than once by calling it again with a different fieldName. Reusing a name replaces that signature instead of adding one.
  • Signatures are invisible — they carry full cryptographic weight and every reader shows them in its signature panel, but nothing is drawn on the page. Placing a visible signature graphic would require a drawing library that is not available in the Dataverse plug-in sandbox.
  • Sign last. Anything that modifies the PDF afterwards — a watermark, a merge, adding pages — invalidates the signature, which is exactly what a signature is for.
Do not store the certificate or its password in Dataverse. Fetch them from Azure Key Vault in the flow at run time and pass them straight into the action. VerseDocs holds them in memory only: they are never written to the usage log, never included in an error message, and never traced. That guarantee ends at the boundary of this action — a flow that parks the key in a variable, a table or a run history is outside it.
This action requires a license. It is also the one action that never applies the trial watermark, because stamping a watermark into a PDF after signing it would invalidate the signature just created.

Handling errors

Every action fails as a standard Dataverse action error: the step turns red and the error body is JSON.

{ "code": "TEMPLATE_FIELD_MISSING", "message": "Template field 'customer.vat' was not found in Data." }

Add Configure run afterhas failed on a following step to branch, and parse the body to read code. Branch on the code, never on the message text — codes are stable, wording is not.

The full list is on Limits & Errors.

What VerseDocs does not do

Worth knowing before you design a flow around an assumption. These are deliberate boundaries, not gaps waiting to be filled:

  • No OCR. Text is extracted from PDFs that contain real, selectable text. A scanned image is not made searchable. Recognise the text upstream with AI Builder, then hand VerseDocs the result.
  • No AI extraction or classification. VerseDocs reads structure it already understands — PDF text layout, form fields, template tokens. Pulling unstructured fields out of a free-form document is AI Builder’s job, upstream.
  • No translation. Translate the data before it enters a template, not the rendered document afterwards.
  • No CAD or InfoPath conversion. The conversion ladder handles Word, Excel and PowerPoint.