Choosing a way to generate documents

Microsoft 365 gives you several ways to turn list data or an app record into a Word or PDF file. They differ in where they start, what they produce, and which licenses they need. This guide compares them, so you can pick one and go straight to the tutorial that builds it.

Three questions to start with

1. Where does the work start? From one item in a SharePoint list, from many items at once, from a Word file already in a library, or from a record in a canvas app.
2. Is premium licensing available? Most approaches use the Word Online (Business) connector, which is a premium connector. The standard-connector approach avoids it, and so does the one-page PDF option in a canvas app.
3. Does the output fit on one page? In a canvas app, a one-page document can be made without a flow.

The approaches side by side

You want to	Starts from	Produces	Connectors	Tutorial
Make a Word file and a PDF from one list item	For a selected item in a SharePoint list	Word and PDF, saved in a library	SharePoint, and Word Online (Business), premium	Create Word and PDF documents from a SharePoint list item
Make files for every item someone has marked	A Yes/No column marking the items, then one run	Word and PDF for each marked item	SharePoint, and Word Online (Business), premium	Batch generate Word and PDF documents from a SharePoint list
Start that batch run from a button on a page	A canvas app button placed on a SharePoint page	The same files as the batch run	SharePoint, and Word Online (Business), premium	Process marked SharePoint items from one Power Apps button on a page
Make a PDF without premium connectors	For a selected item in a SharePoint list	A PDF from a Word template saved as HTML	SharePoint and OneDrive for Business, standard	Generate a PDF from a SharePoint list item with no premium connectors
Convert a Word file that already exists	For a selected file, from a button in a document library	A PDF, saved in a folder you choose	SharePoint, and Word Online (Business), premium	Convert Word files to PDF from a SharePoint library button
Turn a canvas app record into a document	A button in a canvas app	A one-page PDF made in the app, or Word and PDF files from a flow that emails one of them	No flow or Word connector for the one-page PDF. For the flow: SharePoint, Office 365 Outlook, and Word Online (Business), premium	Export a Power Apps form to Word or PDF and email it

Choosing between them

One item, with premium licensing. Start with the single-item tutorial. The batch tutorial and the canvas app export tutorial link back to its steps for building the Word template.

Many items at once. Use the batch tutorial when people mark rows and one run should handle them all, up to the limit the tutorial sets for each run. The marks are shared, so a run processes every marked row, whoever marked it. Add the button tutorial if people should start that run from a page, not from the list’s menu.

No premium licensing. The standard-connector approach fills an HTML version of your Word template and lets OneDrive convert it. The Word file’s look carries over, but some Word features don’t survive saving as HTML, so the tutorial adds the logo and title back.

The Word file already exists. If someone has already written the document and only needs a PDF, the conversion tutorial adds a button to the library that converts the selected file. It doesn’t fill in a template.

The data is in a canvas app. If the record fits on one page, the Power Fx PDF function makes the file in the app, without a flow. It’s an experimental feature, and Microsoft says experimental features aren’t meant for production use. For longer documents, the same tutorial’s second option sends the record’s ID to a flow that fills a Word template and emails the result.

Licensing

Word Online (Business) is a premium connector in Power Automate and in Power Apps. Who needs a license depends on how the flow starts, not on whose connection it uses: connections are independent from license checks.

• A flow started from a SharePoint list or library. Every user who runs an instant flow with premium connectors needs a Power Automate Premium license, unless the flow itself has a Process license. A Process license is assigned to a solution-aware flow, so a flow that needs one has to be in a solution.
• A flow started from a canvas app. The app and the flow are licensed separately.
  1. The app needs whatever its own features require. Some Microsoft 365 licenses include limited Power Apps use rights for apps that use Microsoft 365 data and standard connectors. Premium features need a premium Power Apps license. An app that calls a flow with a premium connector can need premium use rights even when the app itself uses only standard connectors, so those limited rights may not be enough. Microsoft’s license designation page lists a known issue: the designation may not count a premium connector in a flow the app calls, although the app’s users still need premium use rights. Treat the designation as a guide, and check every flow the app calls. Each user needs rights for both the app and the flow.
  2. The premium flow needs one of these:
     • a Power Automate Premium license for each person who runs it;
     • a Process license on the flow;
     • or, if the flow runs in the context of a premium Power Apps app, each user’s Power Apps Premium or Dynamics 365 license. Microsoft treats a flow as in the app’s context when it was created to support the app and uses the same data sources.
  3. A Process license covers the flow’s premium use, but doesn’t replace the app’s license.
• An automated or scheduled flow. These flows use the flow owner’s license context, so with a premium connector, generally only the owner needs a Premium license. That isn’t a way to avoid licensing the people who use it. Microsoft says that when people trigger a flow indirectly, such as by adding an item, and get value from it, not licensing them counts as multiplexing. A Process license on the flow covers its premium use instead. An automated flow in the context of a Power Apps or Dynamics 365 app must be associated with the app, and its owner needs a Power Apps Premium or Dynamics 365 license.

These are Microsoft’s general rules, not an answer for your organization. What anyone needs depends on the whole scenario: the connectors, how the flow starts, any app it serves, the licenses people already have, and who gets value from it. Check the Power Automate licensing FAQ against your own setup before you choose a trigger.

The standard-connector approach uses only standard connectors.

What the Word Online (Business) approaches have in common

These apply to the approaches that use the Word Online (Business) connector. The first three apply where a flow fills a Word template. Each tutorial explains them where they apply.

• Build the template in Word desktop on Windows. The Word Online (Business) connector page says template creation in Word for Mac isn’t supported.
• Check which content controls you use. The same page lists the ones the template action doesn’t support: rich text, building block gallery, date picker, check box and legacy form controls. It also says control names in a template have to be unique, and that line breaks are rendered when a control has Allow carriage returns (multiple paragraphs) turned on.
• Check sign-in policies. The connector page says the Populate a Microsoft Word template action can’t be used if a multifactor authentication (MFA) conditional access policy is enabled.
• Allow a moment before using a new file. The connector page recommends a small delay, about a minute, before a follow-up action uses a file the connector created.
• Check sensitivity labels. According to the connector page, Convert Word Document to PDF doesn’t support files labeled Confidential or Highly Confidential.

File names and repeat runs

This applies to every approach. A second run for the same item, or two runs at once, can reach a file name that’s already taken. The tutorials use three kinds of name:

• Current documents keep a name that never changes. The list and app tutorials use the item’s ID, such as Request-42.docx and Request-42.pdf, and show the title inside the document. Each run replaces them. A name built from the title doesn’t stay with the item: after someone edits the title, the next run makes a new file, and the old one stays.
• Working files go in a folder named after the run, or carry the run’s name. The expression workflow()?['run']?['name'] returns the name of the current run, which is different for every run. To keep one current copy, the finished files are then moved into place with Replace, which leaves the run’s folder empty.
• History copies need a name no other run can have. See Keeping a history below.

One run per item at a time. Each tutorial is meant for one generation of an item’s documents at a time, however it’s started and whoever starts it. None of them enforces that. Run folders stop two runs from sharing a working file, but not from replacing the same final files. Each final file shows the run that last replaced it, and the Word file and the PDF are replaced by separate actions. So:

• When two runs for the same item overlap, the Word file can come from one run and the PDF from the other, and the item may have changed in between.
• A run that fails between the two replacements leaves a new Word file beside an older PDF.
• After a failed run, check both final files. To repair a mismatched pair, wait until no other run for the item is in progress, then run the flow once more. If it succeeds, both files come from it.

Run folders stay in Runs after each run. A failed run keeps its folder, with any working files that weren’t moved out, so you can see how far it got. From time to time, delete old run folders by hand. Before you delete one, make sure no run is in progress, and that the final documents are in place and open correctly.

Keeping a history

Keeping a history is a choice about what builds up over time:

Final file name	What you end up with
Request-<ID>	One current file per item. Each run replaces it
Request-<ID>-<status>	One file per item for each status it has had. A run in the same status replaces that file
Request-<ID>-<date and time>-<run name>	A new file for every run, kept until someone deletes it

For a copy of every run, put the run’s name in the file name. A date and time makes the names easier to read, but two runs can start at the same moment, so on its own it can repeat.

Build the name once, so that the Word file and the PDF match:

1. Before the first Create file, add a Compose named History name. In Inputs, type Request-, select the item’s ID, type -, add the expression below, type -, and add the run-name expression.

   formatDateTime(utcNow(), 'yyyy-MM-dd-HHmmss')

2. In each Create file, set File Name to the Outputs of History name, followed by .docx or .pdf.

Move file keeps the name, so the copies in the destination have the same names. utcNow() returns the current time in UTC, so the time in the name is UTC. Plan how long to keep anything that builds up.

The conversion tutorial is the exception: its PDF takes the Word file’s name, and the tutorial explains what that means after a rename, and how to keep a copy from every run.