DEV Community: DocuGenerate

Generate and Email Certificates of Participation with Pipedream

DocuGenerate — Mon, 28 Sep 2026 00:00:00 +0000

Introduction

Events, workshops, and training programs usually end the same way: every participant expects a certificate, and someone on the organizing team has to produce and send them. Filling in names by hand, exporting each certificate to PDF, and attaching it to an individual email is slow work that doesn’t scale past a handful of attendees, and a single typo in a name is enough to make a certificate unusable. In this tutorial, we’ll build an automated workflow with Pipedream and DocuGenerate that takes care of the whole process, from receiving the participant’s data to delivering the finished PDF to their inbox.

The workflow has three steps. A webhook trigger receives the participant’s details as a JSON payload, the DocuGenerate Generate Document action merges that data into a Word template to produce a PDF certificate, and the Gmail Send Email action sends the certificate to the participant as an attachment. Because the entry point is a plain HTTP endpoint, the same workflow can be called from a registration platform, a form, a spreadsheet script, or your own backend. By the end of this guide, you’ll have a working workflow that you can copy into your own Pipedream account with a single click.

Setting Up the Certificate Template

Before building the workflow, we need a certificate template in DocuGenerate. For this tutorial, we’ll use the Certificate Of Participation Word template, a landscape certificate with an ornate gold border, a large script font for the recipient’s name, a wax seal in the center, and a signature block at the bottom right.

Once you’ve uploaded the template to your DocuGenerate account, 6 merge tags are detected automatically: Full Name, Event Name, Organizer, Certificate ID, Signer Position, and Signer Name. The Full Name tag is displayed prominently in the middle of the certificate, Event Name and Organizer appear in the recognition text below it, and Organizer is also printed inside the wax seal. The Certificate ID sits next to the issuing date, while Signer Name and Signer Position fill the signature block.

The issuing date next to the certificate ID doesn’t need a merge tag at all. It’s a DATE field inserted directly in Word, so it’s filled in with the current date every time a certificate is generated. Our blog post on inserting today’s date in a template explains how to add this kind of field in Word or LibreOffice and choose its display format.

Configuring the Webhook Trigger

With the template ready, we can create a new workflow in Pipedream. Every workflow starts with a trigger, which determines where the data comes from and when the workflow runs. The data could come from a spreadsheet, a database like Airtable or Notion, a form builder, or any other app Pipedream connects to. For this tutorial, we’ll use an HTTP trigger that listens for incoming requests on a unique URL, since it’s the most flexible option and works with any system that can send an HTTP request.

Click Add Trigger and select the New HTTP / Webhook Requests trigger. The default configuration is a good fit for this workflow, so you can leave the parameters as they are:

Event Data : Full HTTP request, which exposes the body, headers, and other request details to the following steps via the steps object.
HTTP Response : Return HTTP 200 OK, so the caller receives an immediate confirmation.
Domains : pipedream.net, the domain used for the generated trigger URL.
Authorization : None, meaning any request sent to the URL is accepted. We’ll come back to this in the production section.

Click Save and continue to create the trigger. In the SELECT EVENT section, Pipedream displays the unique URL generated for this workflow, which in our case is https://eorgxgd03g7mu1b.m.pipedream.net. Any HTTP request sent to this URL will start the workflow.

Sending a Test Event

To configure the next steps, Pipedream needs a sample event so it can show the structure of the incoming data and offer it for autocompletion. Click Generate Test Event , open the Body tab, select application/json as the Content-Type , and enter the following payload in the Raw Request Body field:

{
  "Signer Position": "Program Director",
  "Signer Name": "Margaret Ellison",
  "Certificate ID": "FLN-2025-00143",
  "Organizer": "Future Learning Network",
  "Event Name": "International Student Leadership Forum 2025",
  "Full Name": "Aisha Rahman",
  "Email": "aisha.rahman@example.com"
}

The first six keys match the merge tags in the certificate template exactly. The Email key isn’t used in the template, but we include it in the payload because the workflow needs to know where to send the certificate once it’s generated.

Click Send HTTP Request to submit the test event. The RESULTS section confirms that the request was received and shows how the data is exported under steps.trigger.event. The seven fields from our payload are available in the body object, alongside other request details like the headers, the method, and the url.

Generating the Certificate

Next, click the + button below the trigger, search for DocuGenerate, and select the Generate Document action from the DocuGenerate App. The first time you use it, you’ll need to connect your DocuGenerate account with your API Key. The integration guide covers this setup in more detail.

Configure the action with the following parameters:

DocuGenerate Account : The account connected with your API Key.
Template : The Certificate Of Participation template uploaded in the template setup step.
Name : Certificate for {{steps.trigger.event.body["Full Name"]}}, which gives each document a name based on the participant, such as Certificate for Aisha Rahman.
Format : PDF (.pdf), so the certificate can be attached to an email and opened on any device.
Data : An object mapping each merge tag to the corresponding value from the trigger, as explained below.

For the Data parameter, select the Construct an object option and add one row for each of the 6 merge tags. The key of each row is the merge tag name, and the value references the matching field in steps.trigger.event.body. Keys that contain spaces must use bracket notation, as in {{steps.trigger.event.body["Full Name"]}}, while single-word keys like Organizer can use the shorter dot notation, {{steps.trigger.event.body.Organizer}}. The Email field is left out, since the template doesn’t use it.

Click Test to run the action with the test event. The RESULTS section confirms that the document was generated, and the exported $return_value contains the details of the new document:

{
  "$summary": "Successfully generated the document S1AG7iucebUnYdv9RY73",
  "$return_value": {
    "created": 1790522684107,
    "template_id": "bjBXM4QZeg88Hf7ULwgl",
    "name": "Certificate for Aisha Rahman",
    "format": ".pdf",
    "data_length": 1,
    "filename": "Certificate for Aisha Rahman.pdf",
    "document_uri": "https://firebasestorage.googleapis.com/v0/b/storage.us.docugenerate.com/o/documents%2FS1AG7iucebUnYdv9RY73%2FCertificate%20for%20Aisha%20Rahman.pdf?alt=media&token=81c6ffdb-282d-4a89-a2b9-e96542f6aee2",
    "id": "S1AG7iucebUnYdv9RY73"
  }
}

The two fields we’ll need in the next step are filename, the name of the generated file, and document_uri, a URL pointing to the generated PDF.

You can also verify the result in DocuGenerate. The Documents tab of the Certificate Of Participation template now lists a document named Certificate for Aisha Rahman , with every merge tag replaced by the values from the test event, including the organizer’s name inside the seal and the signer’s details in the signature block. You can download the generated certificate to see the final PDF.

Sending the Certificate by Email

The final step delivers the certificate to the participant. Click the + button below the Generate Document action and select the Send Email action from the Gmail app, then connect the Gmail account the emails should be sent from. Pipedream supports many other email providers, but the Gmail action is complete and quick to set up, which makes it a good choice for this tutorial.

Configure the action with the following parameters:

To : {{steps.trigger.event.body.Email}}, the email address received in the webhook payload.
Subject : Your certificate {{steps.trigger.event.body["Certificate ID"]}}, which includes the certificate ID so the participant can reference it later.
Email Body : A short message personalized with the participant’s name, the event name, and the signer’s details (shown below).
Attachment Filenames : {{steps.generate_document.$return_value.filename}}, the filename returned by the Generate Document action.
Attachments : {{steps.generate_document.$return_value.document_uri}}, the URL of the generated PDF.

Here is the complete text used in the Email Body field:

Dear {{steps.trigger.event.body["Full Name"]}},

Thank you for taking part in {{steps.trigger.event.body["Event Name"]}}.

Please find your certificate of participation attached to this email.

We hope you enjoyed the experience and look forward to seeing you at future events.

Best regards,
{{steps.trigger.event.body["Signer Name"]}}
{{steps.trigger.event.body["Signer Position"]}}

A convenient detail of the Gmail action is that the Attachments field accepts public URLs as well as file paths. This means the document_uri returned by DocuGenerate can be passed directly, without adding an intermediate step to download the PDF to temporary storage first. Click Test to send the email for the test event. The participant receives a message with the subject Your certificate FLN-2025-00143 , the personalized body text, and the certificate attached as Certificate for Aisha Rahman.pdf.

Testing the Workflow End to End

So far, each step has been tested individually using the sample event. To run the complete workflow the way it will run in practice, click Deploy so the trigger URL starts processing live requests. Then send a real HTTP request to the trigger URL from outside Pipedream. If you’re not sure how to do this from your own system, the See Code Examples button in the trigger’s SELECT EVENT section provides ready-made snippets in several languages, including cURL, JavaScript, Node, Python, PHP, Go, and Ruby.

We’ll use the following cURL command, which sends the same participant data as the test event:

curl -X POST https://eorgxgd03g7mu1b.m.pipedream.net \
  -H "Content-Type: application/json" \
  -d '{
    "Signer Position": "Program Director",
    "Signer Name": "Margaret Ellison",
    "Certificate ID": "FLN-2025-00143",
    "Organizer": "Future Learning Network",
    "Event Name": "International Student Leadership Forum 2025",
    "Full Name": "Aisha Rahman",
    "Email": "aisha.rahman@example.com"
  }'

Within a few seconds of sending the request, the workflow runs through all three steps: the trigger receives the payload, DocuGenerate generates the certificate, and Gmail sends it to the participant’s inbox. Each run is recorded in the workflow’s event history in Pipedream, where you can inspect the inputs and exports of every step if something doesn’t look right. To generate certificates for a whole list of participants, send one request per participant with their own details.

If you’d like to try this workflow yourself, you can use this share link to copy it into your own Pipedream account. Connected accounts are not included in shared workflows, so you’ll need to connect your own DocuGenerate and Gmail accounts and select your own copy of the certificate template.

Taking the Workflow to Production

The workflow we’ve built is complete, but a couple of adjustments are worth making before relying on it for a real event. The most important one is the trigger’s Authorization setting. With None, anyone who knows the trigger URL can generate a certificate and have it emailed to any address. Pipedream lets you authorize HTTP requests with a custom token or OAuth, so that only requests from your own systems are accepted and all others are discarded.

The second consideration is where the data comes from. Calling the webhook from a registration platform, a form builder, or your own backend works well when certificates should go out as soon as someone completes an event. If your participant list lives in a spreadsheet or a database instead, you can swap the HTTP trigger for a Pipedream trigger that fires on a new row in Google Sheets or a new record in a database. The Generate Document and Send Email steps stay the same, and only the references to steps.trigger.event.body need to be updated to point at the new trigger’s data.

Conclusion

In this tutorial, we built a Pipedream workflow that turns a single HTTP request into a personalized PDF certificate delivered by email. The webhook trigger receives the participant’s details, the DocuGenerate Generate Document action merges them into a Word template, and the Gmail Send Email action attaches the PDF directly from its URL, with no intermediate download step and no manual work once the workflow is deployed.

The same pattern works for any document that needs to reach a recipient right after it’s created, such as course completion certificates, event tickets, registration confirmations, or receipts. Replace the template, adjust the payload to match its merge tags, and update the email text, and the rest of the workflow remains unchanged.

Resources

The Certificate Of Participation Word template used in this tutorial.
A sample generated PDF showing the final output.
The Certificate of Participation Generator link to copy this workflow in Pipedream.
The DocuGenerate integration guide for Pipedream.
The official DocuGenerate App for Pipedream.
The Gmail Send Email action on Pipedream.

Create Salary Increase Letters with n8n and DocuGenerate

DocuGenerate — Tue, 18 Aug 2026 00:00:00 +0000

Introduction

Salary increase letters are one of those documents that need to go out to every affected employee at the same time, worded consistently, and free of copy-paste mistakes. When a review cycle covers dozens of employees, writing each letter by hand or manually merging a spreadsheet into a Word document quickly becomes a bottleneck for HR teams. In this tutorial, we’ll build an automated workflow using n8n and DocuGenerate that turns a Google Sheets spreadsheet of salary review data into personalized PDF letters, with no manual document creation involved.

The workflow watches a Google Drive folder for a new spreadsheet. As soon as one appears, it reads every row, and for each employee it merges that row’s data into a Word template, generates a PDF, and uploads the finished letter to a dedicated output folder in Drive. HR only has to prepare the spreadsheet with that cycle’s raises; the letters are generated and filed automatically. By the end of this guide, you’ll have a fully functional n8n workflow that you can import and adapt to your own salary review process.

Setting Up the Salary Increase Letter Template

Before building the n8n workflow, we need a document template in DocuGenerate. We’ll use the Salary Increase Letter Word template, a short remuneration review letter that informs an employee of their raise, the new total pay, and who to contact with questions.

Once you’ve uploaded the template to your DocuGenerate account, 13 merge tags are detected automatically: Date, Employee First Name, Employee Last Name, Employee Address, Increase Amount, Remuneration Type, Total Sum, Increase Date, Contact Name, Contact Number, Company Name, Signatory Name, and Signatory Position. These merge tags cover both the employee-specific details of the raise and the fixed details of the company and signatory, all of which will come from the spreadsheet rows.

Preparing the Data in Google Sheets

The data for this workflow lives in Google Sheets. For this tutorial, we’re using the sample Salary Increase Data Excel file, imported into a Google Sheets spreadsheet named Salary Increase August 2026. Each of the 10 rows represents one employee’s raise, with a column for every merge tag in the template: name, address, increase amount, remuneration type, total sum, and the increase date, alongside the shared contact and signatory details repeated on every row.

This spreadsheet lives inside a Salary Increase Letter folder in Google Drive, which also holds the folders of letters generated for past review cycles. Each new cycle starts the same way: a new spreadsheet with that cycle’s data is added to this folder, which is exactly the event our workflow will watch for.

The n8n Workflow Overview

With the template and the data source ready, here’s what the complete workflow looks like in n8n. You can download the workflow JSON file and import it directly into your n8n instance, then update the DocuGenerate template, the Google credentials, and the Drive folder ID to match your own setup.

The workflow begins with a trigger that watches the Salary Increase Letter folder for a new Google Sheets file. When one appears, it creates a matching output folder, reads every row from the sheet, and loops through the rows one at a time, generating a PDF letter for each employee and uploading it to the new folder. Let’s walk through each node.

Watching for New Spreadsheets with the Google Drive Trigger

The Google Drive Trigger node polls a specific Google Drive folder and starts the workflow when a matching change occurs.

The node is set to poll Every X 30 Minutes , with Trigger On set to Changes Involving a Specific Folder. The Folder parameter accepts the target folder in three ways: From list , By URL , or By ID ; here it’s set to By ID with the ID of the Salary Increase Letter folder.

You can find a folder’s ID in its Google Drive URL, it’s the string of characters after /folders/. For example, the ID for the URL https://drive.google.com/drive/folders/1dcLLzfZaH38hDd0acfUru2ISOoTsbGPI is 1dcLLzfZaH38hDd0acfUru2ISOoTsbGPI.

Finally, Watch For is set to File Created , and the File Type option under Options is restricted to Google Spreadsheets , so the trigger only fires when a new spreadsheet is added to the folder.

Creating an Output Folder

Once a new spreadsheet is detected, the workflow needs somewhere to put the generated letters. The Google Drive node’s Create operation on the Folder resource handles this.

The Folder Name parameter uses the expression {{ $('Google Drive Trigger').item.json.name }}, which resolves to Salary Increase August 2026, the name of the spreadsheet that triggered the workflow. The Parent Folder is set to the same folder ID used in the trigger, so the new output folder is created as a sibling of the source spreadsheet inside Salary Increase Letter. Naming the folder after its source spreadsheet keeps each review cycle’s letters grouped with the data that produced them.

Reading the Employee Data

With the destination folder ready, the Google Sheets node’s Get Row(s) operation on the Sheet Within Document resource reads the employee data.

The Document is set to Salary Increase August 2026 and the Sheet to Salary Increase Data , both picked from the From list dropdowns. The node returns all 10 rows as separate items, each containing the full set of fields we saw in the spreadsheet: employee details, raise figures, and the shared contact and signatory information.

Looping Through Each Employee

To generate one letter per employee, the workflow needs to process the 10 rows one at a time. The Loop Over Items node handles this with a batch size of 1.

Each pass through the loop carries a single employee’s row, such as the first one for James Mitchell with a 4% increase bringing his annual salary to $87,500, into the nodes that follow. The loop continues until all 10 rows have been processed, generating and saving one letter before moving on to the next.

Generating the Letter

The Generate document node uses the DocuGenerate integration for n8n to merge each row’s data with the Word template. To use this node, install DocuGenerate in your n8n instance and configure it with your API Key.

The node is configured with the following parameters:

Template Name or ID : The Salary Increase Letter template uploaded earlier.
Name : An expression, Letter for {{ $json['Employee First Name'] }} {{ $json['Employee Last Name'] }}, which produces a name like Letter for James Mitchell for the first row.
Format : Set to PDF (.pdf).
Data : Set to {{ $json }}, passing the entire current row, with all 13 merge tag values, straight to the API.

For the first row, this produces the following response:

[
  {
    "created": 1774348731006,
    "template_id": "ARnboMDE3zyzMrdTZJ2e",
    "name": "Letter for James Mitchell",
    "format": ".pdf",
    "data_length": 1,
    "filename": "Letter for James Mitchell.pdf",
    "document_uri": "https://firebasestorage.googleapis.com/v0/b/storage.us.docugenerate.com/o/documents%2FA1blGMwZETC4hrP5Zr2C%2FLetter%20for%20James%20Mitchell.pdf?alt=media&token=6383b541-f2b9-4c79-8161-063d287a5887",
    "id": "A1blGMwZETC4hrP5Zr2C"
  }
]

You can see the generated document below, or download the sample PDF directly.

Downloading the Generated Letter

DocuGenerate returns a document_uri pointing to the generated PDF rather than the file itself, so the workflow needs to fetch it before it can be uploaded elsewhere. The HTTP Request node makes a GET request to that URL.

The URL parameter is set to {{ $json.document_uri }}, referencing the Generate document node’s response. Authentication is left as None, since the document URI already includes an access token. The node’s output holds the file’s binary content in a data field, ready for the next step.

Saving the Letter to Google Drive

The final node uploads the PDF to the output folder created at the start of the run, using the Google Drive node’s Upload operation on the File resource.

The Input Data Field Name is set to data, matching the binary field produced by the HTTP Request node. The File Name field is left empty, so the upload keeps the original filename carried in the binary data, Letter for James Mitchell.pdf for this row. The Parent Folder uses the expression {{ $('Create folder').item.json.id }}, so every letter lands in the folder created for this review cycle rather than loose in Drive.

Running the Workflow

With every node configured, adding a new spreadsheet to the Salary Increase Letter folder is all it takes to generate a full batch of letters. The animation below shows a full run: each node turns green with a checkmark as it completes, and the Loop Over Items segment runs 10 times in a row, once for every employee in the spreadsheet.

Once the run finishes, all 10 letters are sitting in the output folder in Google Drive, each named after its recipient.

Conclusion

In this tutorial, we built an n8n workflow that turns a Google Sheets spreadsheet of salary review data into a folder of personalized PDF letters, with no manual document creation involved. The workflow watches a Drive folder for a new spreadsheet, creates a matching output folder, loops through every row, and generates and files a letter for each employee, all triggered by nothing more than adding a spreadsheet to the right folder.

The same pattern applies to any HR document tied to a periodic review, from bonus letters to renewal notices. The trigger and data source could just as easily be a webhook from a Human Resources Information System (HRIS) or a query against a database instead of a Drive folder, while the generation and delivery steps stay the same.

Resources

The Salary Increase Letter Word template used in this tutorial.
The sample Excel file with employee raise data.
The workflow JSON file that you can import into your n8n instance.
A sample generated PDF showing the final output.
The DocuGenerate integration guide for n8n.

Generate Form W-9 PDFs with Power Automate and Smartsheet

DocuGenerate — Fri, 24 Jul 2026 00:00:00 +0000

Introduction

Form W-9, “Request for Taxpayer Identification Number and Certification,” is an IRS form that businesses in the United States use to collect the legal name, address, and taxpayer identification number of vendors, freelancers, and independent contractors before paying them. The information reported on a W-9 is later used to prepare 1099 forms at tax time, which makes accurate and consistently formatted W-9 records an important part of any vendor onboarding process. Companies that work with a steady stream of new contractors often end up managing this data in a spreadsheet or a tool like Smartsheet, which makes it a natural candidate for automation.

In this tutorial, we’ll build a Power Automate flow that watches a Smartsheet sheet for new rows and automatically generates a filled-in W-9 PDF using DocuGenerate. Whenever a new vendor record is added to the sheet, whether by a team member entering it directly or by an import from another system, the flow merges that row’s data into a Word template and saves the finished PDF to Azure File Storage. The same pattern applies to any document that needs to be generated automatically from spreadsheet data, but a tax form is a good illustration because it involves a mix of individual and business filers, conditional fields, and a layout that must remain precise.

Preparing the DocuGenerate Template

The first step is to create a Word template in DocuGenerate that mirrors the official W-9 layout. We started from the IRS Form W-9 and replaced each fillable field with a merge tag, then uploaded it as a new template named Form W-9.

The template contains 17 merge tags: firstName, lastName, businessName, taxClassification, exemptPayeeCode, fatcaCode, streetAddress, requesterName, requesterAddress, city, state, zipCode, accountNumber, ssn, ein, signature, and signatureDate. Most of these map directly to a labeled box on the form. taxClassification corresponds to the “Other” line in the federal tax classification section and holds a short description such as “C Corporation” or “Trust/estate,” while ssn and ein populate the two boxes in Part I depending on whether the filer is an individual or a business entity. You can download the Word template used in this tutorial and adapt it to your own layout.

Setting Up the Data Source in Smartsheet

With the template in place, the next step is to prepare the sheet that will act as the trigger for our flow. In Smartsheet, click Create > Sheet > Table to create a new sheet, then rename it to Form W-9. Rather than typing sample rows in by hand, we’ll import them from an Excel file by opening the sheet menu and selecting Import. Keep in mind that importing replaces any existing data in the sheet with the data from the source file.

You can download the sample Excel file used for this import. It contains 10 rows matching the 18 columns that will map to the merge tags in the template: a Record ID column (REC-001 through REC-010) followed by one column for each field on the form. The data mixes individuals and business entities to exercise the different branches of the form: six individuals or sole proprietors with an SSN and no EIN, and four entities (an LLC, a C Corp, a trust/estate, and a partnership) with an EIN and no SSN. One row also has the Exempt Payee Code and FATCA Code columns populated, since those only apply in specific cases.

Building the Power Automate Flow

With the template and the data source ready, we can build the flow itself. In Power Automate, click New flow > Automated cloud flow. In the Build an automated cloud flow dialog, give the flow a name such as Form W-9, search for “Smartsheet” in the trigger list, and select When a new row is created.

The flow we’ll build has three steps: a Smartsheet trigger that fires when a row is added, a DocuGenerate action that generates the PDF, and an Azure File Storage action that saves it. Let’s configure each one in turn.

Configuring the Smartsheet Trigger

The When a new row is created trigger needs a connection to your Smartsheet account, which Power Automate will prompt you to create the first time you use it. Once connected, set the Sheet Id parameter to the Form W-9 sheet we created earlier.

Adding the Generate Document Action

Next, click the + button below the trigger and search for “DocuGenerate” to see the list of available actions.

Select Generate Document. The first time you use a DocuGenerate action in your environment, you’ll be prompted to create a connection using your DocuGenerate API Key. Once connected, set the Template field to the Form W-9 template created in DocuGenerate.

For the Data field, we need a JSON object containing the values for all 17 merge tags. Smartsheet’s trigger does not expose the row’s cells by column name, only as an array, so each value has to be referenced by its numeric index. Based on how the columns were ordered during the import, the mapping is: column 0 is Record ID, column 1 is SSN, column 2 is First Name, column 3 is Last Name, and so on through column 17, which is Signature Date. We built the JSON with the concat and json expressions:

json(concat(
  '{"firstName": "', triggerBody()?.cells?[2]?.value,
  '", "lastName": "', triggerBody()?.cells?[3]?.value,
  '", "businessName": "', triggerBody()?.cells?[4]?.value,
  '", "taxClassification": "', triggerBody()?.cells?[5]?.value,
  '", "exemptPayeeCode": "', triggerBody()?.cells?[6]?.value,
  '", "fatcaCode": "', triggerBody()?.cells?[7]?.value,
  '", "streetAddress": "', triggerBody()?.cells?[8]?.value,
  '", "requesterName": "', triggerBody()?.cells?[9]?.value,
  '", "requesterAddress": "', triggerBody()?.cells?[10]?.value,
  '", "city": "', triggerBody()?.cells?[11]?.value,
  '", "state": "', triggerBody()?.cells?[12]?.value,
  '", "zipCode": "', triggerBody()?.cells?[13]?.value,
  '", "accountNumber": "', triggerBody()?.cells?[14]?.value,
  '", "ssn": "', triggerBody()?.cells?[1]?.value,
  '", "ein": "', triggerBody()?.cells?[15]?.value,
  '", "signature": "', triggerBody()?.cells?[16]?.value,
  '", "signatureDate": "', triggerBody()?.cells?[17]?.value,
  '"}'
))

The ? characters are null-conditional operators: triggerBody()?.cells?[2]?.value reads the value property of the cell at index 2, and returns null instead of throwing an error at any point where cells or that specific cell happens to be missing. This matters here because several columns, like businessName or ssn, are intentionally blank on many rows. The outer concat function stitches all these values into a single JSON string, and json() parses that string into the object the Data field expects.

For the Name field, we used an expression that checks whether the Business Name column (index 4) is populated and picks the appropriate naming pattern, using the same index map as above:

if(
  empty(triggerBody()?.cells?[4]?.value),
  concat('Form W-9 ', triggerBody()?.cells?[2]?.value, ' ', triggerBody()?.cells?[3]?.value),
  concat('Form W-9 ', triggerBody()?.cells?[4]?.value)
)

This produces a name like “Form W-9 John Smith” for an individual filer, or “Form W-9 Bluepeak Software LLC” for a business filer. Finally, leave the Format field set to its default value of .pdf.

Saving the Document to Azure File Storage

Once the document is generated, there are many ways to deliver it: send it by email, add it to SharePoint or OneDrive, upload it to an S3 bucket, and so on. For this tutorial, we’ll save it to Azure File Storage. Click the + button below the Generate Document action, search for “Create file,” and select the action from Azure File Storage.

Create a connection by providing a Connection name , your Azure Storage account name or file endpoint , and your Azure Storage Account Access Key , both of which are available from your storage account in the Azure portal.

With the connection in place, configure the Create file action:

Folder path : /form-w-9, the destination folder in the storage account.
File name : outputs('Generate_Document')?['body/filename'], the filename of the generated PDF.
File content : outputs('Generate_Document')?['body/document_uri'], the generated PDF URL.

Testing the Flow

To test the flow, click Test on the flow page, select Manually , then click Test again. Power Automate will display a message asking you to add a row to the selected sheet to trigger the run.

Add a new row to the Form W-9 sheet in Smartsheet with a fresh set of vendor details. Once the flow runs, the generated document appears in the Documents panel of the Form W-9 template in DocuGenerate, and the PDF is saved to the specified folder in Azure File Storage. You can see an example of the generated PDF below.

Conclusion

This tutorial covered the full path from a row in Smartsheet to a ready-to-file W-9 PDF, using a Power Automate flow with no custom code involved. The trigger detects new vendor records as they’re entered, the Generate Document action fills in the official form layout with that row’s data, and the Create file action delivers the result to Azure File Storage automatically.

The same three-step pattern (trigger, generate, deliver) works for any recurring document your team produces from spreadsheet or table data, whether that’s onboarding paperwork, invoices, or compliance forms. Because the DocuGenerate actions are available across the whole Power Platform, you could just as easily trigger this flow from a Power Apps form or a SharePoint list instead of a Smartsheet row, while keeping the same Generate Document configuration.

Resources

The Form W-9 Word template used in this tutorial.
The sample Excel file with vendor data for import into Smartsheet.
A sample generated PDF showing the final output.
The Smartsheet connector reference for Power Automate.
The Azure File Storage connector reference for Power Automate.
The DocuGenerate connector reference for Power Automate.
The official IRS Form W-9 and instructions.

Organize Your Templates in Folders for Easy Access

DocuGenerate — Mon, 15 Jun 2026 00:00:00 +0000

What are Template Folders?

Template Folders bring a familiar organizational model to DocuGenerate, allowing you to group related templates together in a hierarchical structure. Whether you’re managing a handful of templates or hundreds, folders provide a clean, intuitive way to find what you need and keep your template library organized as it grows.

Until now, all templates in your DocuGenerate account were displayed in a single flat list, sorted by creation date. With this new feature, we’re introducing a folder system that follows the conventions you already know from file managers and email clients, with arbitrary nesting depth, intuitive reorganization, and full support across both the web app and the API.

Why Folder Organization Matters

For organizations that rely on a growing library of templates, the absence of organizational structure can become a real productivity drag over time. As your template library grows from a few dozen to hundreds of templates, locating the right one becomes harder, onboarding new team members slows down, and templates drift apart from any logical structure that once existed in someone’s head.

1. Faster Template Discovery

With folders, you no longer need to scroll through a long list of templates or rely on partial name matching to find the right one. A well-organized folder hierarchy mirrors how your team actually thinks about templates, whether by department, by client, by document type, or by project phase.

2. Clearer Mental Model for Teams

When templates are organized into folders, the structure itself communicates intent. A new team member looking at your template library can quickly grasp how documents are categorized in your organization, reducing the need for explanations or onboarding documentation.

3. Filterable Views

Folders aren’t just visual containers. Selecting a folder filters the templates view to show only the templates inside it, giving you a focused workspace when you’re working within a specific category. The current folder is reflected in the page URL, so you can bookmark or share a filtered view.

How Template Folders Work in the Web App

Folders are accessible throughout the app via the folder icon in the navbar. Clicking it opens the folder menu, which displays your folder tree and lets you create, edit, or delete folders directly. On mobile devices, the folder menu is available from the main user menu.

Creating a Folder

To create a new folder, click the New Folder icon next to the Template Folders header in the folder menu. A dialog opens where you can enter the folder name and optionally select a parent folder if you want to create the folder inside an existing one.

To create a sub-folder directly from an existing folder, you can also use the Add action in the folder’s context menu, which pre-fills the parent selection for you. Folder names support letters, numbers, and spaces. Each folder gets a unique URL derived from its name, as described in the filtering section below.

Assigning Templates to Folders

You can assign a template to a folder either when creating a new template or by editing an existing template’s settings. The folder dropdown in the template settings shows the full tree of available folders, with indentation reflecting the parent-child relationships.

Each template belongs to a single folder at a time. To move a template to a different folder, you change the folder selection in the template settings and save. To remove a template from any folder, you select None in the folder dropdown.

Filtering Templates by Folder

Selecting a folder in the folder menu filters the templates view to show only the templates within that folder. The page URL updates to reflect the current filter. This means you can bookmark a folder view, share the URL with a teammate, or open multiple browser tabs each focused on a different folder.

The folder breadcrumb appears in the navbar, showing the full path of the selected folder. To return to the default view with all the templates, click the Clear Folder icon next to the breadcrumb or select All Templates in the folder menu.

The folder a template belongs to is visible in both Grid and List views of the templates page. In the Grid view, the folder name appears under the template title alongside a small folder icon. In the List view, a dedicated Folder column shows the same information. Clicking the folder name in either view filters the templates list to that folder.

Editing, Moving, and Deleting Folders

Each folder in the folder menu has a context menu with three actions: Edit to rename the folder or change its parent, Delete to remove the folder and all its sub-folders, and Add to create a new sub-folder inside it.

When you delete a folder, all of its sub-folders are also removed. Templates inside deleted folders are not themselves deleted, they simply become orphaned and return to the All Templates view. This means deleting a folder is always a safe operation from the perspective of your template content.

Moving a folder under a different parent is supported, with one safety guard: a folder cannot be moved into itself or any of its own descendants. The folder dialog automatically disables those options when you’re editing an existing folder, so the constraint is enforced visually before you can even attempt an invalid move.

Folders for Team Collaboration

For users with the team collaboration feature, folder organization extends naturally to shared templates. Team members see their team owner’s folders in a dedicated Shared section within the folder menu, separated from their own folders by a visual divider.

The visibility model is intentional: team members can browse and filter by the team owner’s shared folders, but they cannot create, rename, or delete folders in the team owner’s hierarchy. This keeps the folder structure consistent across the team and gives the owner clear ownership of how templates are organized for everyone.

When a team member is added or removed, the folder structure reflects this change immediately, without requiring any action on the member’s part. Similarly, when the owner makes changes to their folder structure, those changes propagate to every team member’s view as soon as they’re saved.

Folder Support in the API

For users who manage templates through the DocuGenerate API, folder organization is accessible through the same endpoints you already use. The folder a template belongs to is represented as a folder parameter on the template, expressed as an array of folder names that traces the path from the root to the assigned folder. For example, a template inside a sub-folder named “Contracts” within a parent folder named “Legal” has its folder field set to ["Legal", "Contracts"].

Specifying a Folder When Creating a Template

When creating a template via the API, you can include the folder parameter in your request to assign the template to a specific folder. If the folder path doesn’t yet exist in your account, DocuGenerate creates it automatically, including any intermediate folders along the way.

This auto-creation behavior makes it easy to set up your folder structure programmatically as you create templates, without needing to pre-configure the hierarchy through the web app first.

Moving Templates Between Folders

To move an existing template to a different folder, you can use the update template endpoint with a new value for the folder parameter. Setting it to an empty array ([]) removes the template from any folder, returning it to the orphaned state.

As with template creation, if the new folder path doesn’t exist yet, DocuGenerate creates the missing folders automatically (provided you’re the template owner). Team members with write permission on a shared template can update the template’s contents and settings, but they cannot create new folders in the template owner’s hierarchy, mirroring the web app behavior.

Filtering Templates by Folder

The list templates endpoint accepts a folder query parameter that filters the response to a specific folder. The parameter takes the same form as for the creating or updating a template, expressed as an array of folder names that traces the path from the root to the assigned folder.

This filter follows the same logic as the web app filtering: selecting a folder returns only templates directly assigned to it, not templates from any sub-folders. To gather templates from a folder and all of its sub-folders, you’d issue separate requests for each sub-folder.

Use Case Scenarios

Let’s explore some real-world scenarios where template folders can provide significant value.

Scenario 1: Department-based Organization

A mid-sized company uses DocuGenerate to manage templates across multiple departments: HR, Legal, Sales, and Finance. With dozens of templates in each department, finding the right one had become time-consuming, and new hires struggled to locate the templates relevant to their role.

After organizing templates into top-level folders by department, with sub-folders for specific document types (offer letters, contracts, proposals, invoices), team members can navigate directly to their department’s folder and see only the templates relevant to them. Shareable folder URLs are added to each team’s onboarding documentation, giving new hires a direct link to the templates they’ll be using from day one.

Scenario 2: Client-based Organization for an Agency

A marketing agency generates personalized contracts, proposals, and reports for dozens of clients, each with their own branding and terms. Before folders, the agency’s team relied on a naming convention like [client-name]_[document-type] to locate templates, but this created long, hard-to-scan template names and made it difficult to onboard new account managers.

By creating a top-level folder per client and organizing document types as sub-folders, the agency’s account managers can now browse a clean, hierarchical view of all materials for any given client. When onboarding a new client, the account manager creates a new client folder and replicates the standard sub-folder structure inside it.

Scenario 3: Programmatic Folder Setup via API

A document automation team integrates DocuGenerate into their internal tooling, generating templates programmatically from a database of document patterns. Their internal system organizes patterns by region and document category, and they want their DocuGenerate account to mirror that structure exactly.

Using the API, their integration sends the appropriate folder parameter when creating each template, automatically building out a folder hierarchy that matches their internal taxonomy. This keeps their DocuGenerate account synchronized with their source-of-truth without any manual folder management in the web app, even as their pattern catalog evolves.

Best Practices for Folder Organization

To get the most out of template folders as your library grows, consider these practices that help keep your structure useful and maintainable over time:

Start with broad categories and refine as needed. Resist the temptation to create deep folder hierarchies from day one. Begin with a few top-level folders that match the highest-level distinctions in your workflow, and add sub-folders only when a category accumulates enough templates to justify subdivision.
Match folders to how your team thinks, not how your data is structured. A folder structure works best when it reflects the mental model your team already uses. If everyone refers to “Q1 contracts” rather than “January through March contracts”, let the folder name match the spoken vocabulary, even if it diverges from your internal naming standards.
Use shareable folder URLs for onboarding. When new team members join, share direct links to the folders they’ll be working with most often. This shortens the learning curve significantly and ensures everyone is aware of the relevant templates from the start.
Re-evaluate periodically. Folder structures that made sense a year ago may not match how your team works today. Schedule a periodic review (quarterly or semi-annually) to consolidate underused folders, split folders that have grown too large, or restructure entirely if your workflow has changed substantially.

Conclusion

Template Folders are one of the most-requested additions to DocuGenerate, and we’re glad to finally deliver an organizational model that scales with your template library. Whether you’re managing a small handful of templates or hundreds across multiple departments and clients, folders give you the structure and flexibility to find what you need and share it with your team.

As always, we welcome your feedback as you start organizing your templates with this new feature. We’re particularly interested in hearing about workflows where folders save your team meaningful time, as well as any rough edges you encounter in real-world use that we should consider for future improvements.

Resources

Format Dates in Templates with Data Filters and Automatic Fields

DocuGenerate — Sun, 31 May 2026 00:00:00 +0000

Introduction

Dates appear in nearly every business document. Contracts specify effective dates, invoices carry due dates, certificates bear issuance dates, and recommendation letters are dated to establish their relevance. How those dates are presented matters, because date format conventions vary significantly by country and region. In the United States, the standard format is MM/DD/YYYY, while most of Europe and much of the rest of the world uses DD/MM/YYYY. Without control over date formatting, a date like December 4, 2026 could appear as 12/04/2026 to a US reader or 04/12/2026 to a European one, with each reading it correctly only for their own convention.

DocuGenerate gives you two distinct ways to control how dates appear in your generated documents, each suited to a different use case. The first is the date filter, which formats a date value supplied by your data set and renders it in whatever output format you specify. The second is inserting the current date directly into the document template using Word or LibreOffice, so the field is populated with today’s date automatically at generation time.

This article walks through both approaches using the Recommendation Letter template from our Template Library. For each approach, we’ll show how to produce both US and European date formats, so you have a concrete reference regardless of which convention your documents follow.

Formatting Dates from Your Data Set

When your data set contains date values, DocuGenerate’s date filter gives you full control over how those dates appear in the generated document. This is the right approach when the date is a meaningful piece of data tied to a specific event, such as the signing date of a contract or the date a letter is formally addressed.

The filter is part of the enhanced syntax feature set, so you need to enable it before it takes effect. To do that, open the template, go to Settings , check the Enable enhanced syntax checkbox, and click Save.

Preparing the Data

The date filter expects the input value to be in ISO 8601 format, specifically yyyy-MM-dd. This is an internationally recognized standard for representing dates that avoids the ambiguity of regional conventions. If your data currently stores dates in another format, you will need to convert them to the ISO format before passing them to DocuGenerate. The filter is ignored for non-ISO formatted dates, and the input value will be displayed as-is in the generated document.

Updating the Template

The original template uses the default DocuGenerate syntax with square bracket delimiters. When enhanced syntax is enabled, the tag parser is stricter and does not tolerate extra whitespace inside merge tags, so tags like [Job Title] need to become [Job_Title]. The updated template has already been edited to have whitespace-free tags and is ready for use with enhanced syntax.

Applying the Date Filter

With enhanced syntax enabled, you can format the date directly inside the merge tag using the following syntax:

[Date | date:'date_format']

The date_format string uses symbols from the Unicode Technical Standard for date and time patterns. The two most commonly needed formats for US and European conventions are:

| Merge Tag | Result | Convention |
| --- | --- | --- |
| [Date | date:'MM/dd/yyyy'] | 12/04/2026 | US (Month/Day/Year) |
| [Date | date:'dd/MM/yyyy'] | 04/12/2026 | European (Day/Month/Year) |
| [Date | date:'MMMM d, yyyy'] | December 4, 2026 | Written month name |
| [Date | date:'dd-MM-yyyy'] | 04-12-2026 | European with dashes |

The filter also supports more expressive formats if you need to show the full month name, include the day of the week, or add time components. For a complete list of formatting options and examples, see the How to format data with filters article from our Help Center.

Inserting Today’s Date in the Template

For documents where the date should always reflect the current date at generation time, passing a date through the data set is unnecessary. A recommendation letter, a daily status report, or an ad-hoc certificate typically just needs today’s date, and it would be redundant to include it in every API request or spreadsheet row. For these cases, you can insert a date field directly into the Word template. When DocuGenerate processes the document, the field evaluates and outputs the current date automatically, without any date value in the data at all.

Adding Today’s Date in Microsoft Word

Microsoft Word lets you insert the current date through the Date & Time field. This opens a dialog with a list of date and time formats and a checkbox labeled Update automatically. Selecting this option converts the static date into a live field that updates whenever the document is opened or processed.

The available formats in Word are predetermined and tied to the system’s regional settings. You can change the language from the drop-down menu and the available formats list is updated to match the selected language.

If you want more control over the date format, you can choose to Insert a Field instead, and select the Date and Time category and the Date field name. Click on Options to select from a list of pre-defined date formats, or enter the desired format in the Field code text input. To get the same result and have the date formatted for the French language, you’ll need to use the DATE \@ "dd/MM/yyyy" value in the field code. But this requires familiarity with Word’s field syntax and is not practical for most users.

For a template built using this approach, see the Word-specific template, where the [Date] merge tag has been replaced with Word’s automatic date field set to the European format.

Adding Today’s Date in LibreOffice

LibreOffice Writer provides a more flexible way to insert today’s date, with locale-aware formatting that covers a wide range of regional date conventions. To insert a date field, go to Insert > Field > Date (variable), which adds a date field to your document using a default format. Right-click on the newly inserted date and select Edit Fields , which opens the Fields dialog.

In this dialog, the Format column on the right displays a list of predefined formats for the default system language. These defaults cover common patterns, but to access formats for different locales, click the Additional formats option.

This opens a new dialog where LibreOffice’s date formatting capability becomes particularly useful. A Language dropdown on the right side of the dialog lets you select from hundreds of language and locale combinations. Once you pick a language, the Format list updates to show date patterns that are natural to that locale.

For example, selecting French (France) makes patterns like JJ/MM/AAAA available, which is the French notation for DD/MM/YYYY. You can also type a custom format code directly into the Format Code field if none of the listed options matches what you need.

For a template built this way, see the LibreOffice-specific template. This approach is particularly practical when you maintain multiple variants of the same template for different regions. Each version can use the same content but have the date field configured for the target locale, ensuring the output matches local expectations without modifying the data or the generation workflow.

Choosing the Right Approach

The two approaches address different scenarios and can both apply within the same organization depending on the document type. The date filter is the right choice when the date is a meaningful data field tied to a specific event. A contract’s signing date, an invoice’s due date, or a letter’s reference date all belong in the data, and the filter lets you render them in whatever regional convention the recipient expects. Since it takes a single ISO 8601 input and formats it on output, you can serve US and European audiences with the same data by simply changing the format string in the template.

Inserting today’s date directly in the template is the right choice when no date value exists in the data and the document simply needs to be stamped with the current date. This keeps the data set clean and the generation request simple. Teams that generate documents for multiple regions often maintain a set of locale-specific templates, each with the date field pre-configured for its target audience, and point each regional workflow at the appropriate template.

Conclusion

Getting dates to display correctly in generated documents comes down to identifying where the date value comes from. If it comes from your data set, use DocuGenerate’s filter with a format string that matches your target convention. If the document should always reflect today’s date, insert a date field into the template using Word or LibreOffice, for more advanced locale control. Both approaches work with the same template format and fit naturally into DocuGenerate’s generation workflow without requiring any changes to how documents are generated or delivered.

Resources

The Recommendation Letter template configured for the date filter.
The Recommendation Letter template using Word’s automatic date field.
The Recommendation Letter template using LibreOffice’s date field.
DocuGenerate’s Help Center article on how to format data with filters.
Microsoft’s documentation on inserting today’s date in a Word document.

Mail Merge using DocuGenerate Compared to Microsoft Word

DocuGenerate — Wed, 22 Apr 2026 00:00:00 +0000

Introduction

Mail merge is the process of combining a document template with a data source to produce multiple personalized documents in one operation. It is commonly used for contracts, offer letters, invoices, certificates, and any other document where the overall structure stays the same but specific fields change per recipient or record. Microsoft Word has included mail merge as a built-in feature for decades, making it a familiar starting point for many teams already working in the Microsoft 365 ecosystem. Dedicated document generation platforms like DocuGenerate approach the same problem differently: cloud-based processing, a REST API, and a set of template features that extend well beyond what Word supports natively.

In this article, we evaluate both approaches using the same template and data file so the results are directly comparable. We walk through each workflow from start to finish, then examine how the two tools handle specific features including output formats, bulk generation, dynamic filenames, conditional content, images, and QR codes. The goal is not to pick a universal winner but to give you a clear picture of where each tool fits so you can choose the right one for your workflow.

The Sample Files

To keep the comparison grounded, both workflows in this article use the same two files. The template is the Employment Contract.docx Word document from our Template Library. It contains merge fields for employee details, contract dates, compensation, and other standard contract terms.

The data source is the matching Employment Contract.xlsx spreadsheet, where each row represents one employee and the column headers correspond exactly to the merge field names in the template.

One thing to note is that the column names in the spreadsheet must match the merge tag names in the template exactly for either tool to work correctly. This is a requirement shared by both Word and DocuGenerate, and it applies regardless of which delimiter format is used.

Mail Merge in Microsoft Word

Word’s mail merge is accessible from the Mailings tab, which provides a structured workflow for connecting a template to a data source, inserting fields, previewing the output, and completing the merge. All of this happens locally within the Word application.

Connecting the Excel Data Source

To begin a mail merge, open the Employment Contract template in Word and navigate to Mailings > Select Recipients > Use an Existing List. Word will prompt you to select a file. After selecting Employment Contract.xlsx, a dialog appears asking you to choose which sheet to use as the data source, which is useful when your workbook contains multiple tabs.

With the data source connected, Word reads the column headers and makes them available as merge fields throughout the session. You can also open Edit Recipient List to filter records, sort them, or exclude specific rows before running the merge.

One thing to be aware of: when saving the Word template after connecting it to an Excel file, it stores the path to that file inside the document. If the Excel file is later moved, renamed, or deleted, reopening the template will trigger an error saying “Word cannot find its data source”. It will then prompt you to locate the file again or remove the data source link entirely. This linking behavior means the template and data file need to stay in sync, which can become a maintenance concern when sharing templates across a team.

Inserting the Merge Fields

Once the data source is connected, you can place merge fields anywhere in the template using Mailings > Insert Merge Field. Word wraps each field in its fixed «Field_Name» delimiter format, using guillemet characters that are inserted through the interface rather than typed directly. This delimiter format is not configurable: all Word mail merge fields use «» and cannot be changed to another character pair.

Note that Word replaces the spaces in the column names with underscores when creating the field names for the merge. So the column named Contract Date in the spreadsheet becomes «Contract_Date» in the merge field list. This works fine in Word, but it’s useful to keep that in mind if you want to use the same template in DocuGenerate, for example, because the column names in Excel will no longer match the merge tags exactly.

Previewing the Results

The Preview Results button on the Mailings tab replaces each merge field with the corresponding value from the first row of data. Navigation arrows let you step through the remaining records to spot-check the output before committing to the full merge. This instant preview is one of Word’s most useful features for template development.

Completing the Merge

With the template verified, Finish & Merge offers three options: edit the merged documents in a new Word file, send directly to a printer, or send as individual email messages via Outlook. Selecting Edit Individual Documents produces a single Word file where each merged record is separated by a page break.

You can download a copy of the merged document to see what the output looks like. To get a PDF, you need to save or export that file manually after it was generated.

Word does not generate individual files per record as part of the merge process. The entire workflow is desktop-only: there is no API, no cloud processing, and no way to trigger a mail merge programmatically from another application.

Mail Merge in DocuGenerate

DocuGenerate is a cloud-based document generation platform that works from a web app and a REST API. The template remains a standard DOCX file, so you can design and edit it in Word as usual. The generation step happens in the cloud and produces the final document without requiring any local software beyond a browser or an HTTP client.

Setting Up the Template

To get started, upload the Employment Contract template from the New Template page in the web app. DocuGenerate reads the merge tags from the document and uses them as the fields to populate at generation time.

The merge tags can use square brackets [] as delimiters, but it’s also possible to customize the delimiters to any character pair you prefer, including the Word-style «» guillemets if you want to reuse an existing Word mail merge template without modifying it.

Generating from Excel

To generate documents from Excel, click New Document on the template, choose the Excel or CSV file option, and upload Employment Contract.xlsx. DocuGenerate detects the sheets in the workbook and lets you choose which one to use. As with Word, the column names in the spreadsheet must match the merge tag names in the template exactly for the generation to succeed.

From the Data Items section, you can select which records to use for the merge by clicking on them. By default, all the records in the spreadsheet are used for generating the documents.

The merge export format can be a Word document, matching Word’s native output, or a PDF generated directly in the cloud. For multiple records, you can either combine all documents into a single file (see Employment Contracts.docx for an example) or download them as separate files grouped in a ZIP archive (see Employment Contracts.zip).

Generating via the API

DocuGenerate also exposes an API that lets you trigger document generation from any external system. When generating from an Excel file via the API, you pass the file as a parameter, and optionally the sheet parameter to specify which tab to use. While the web app supports row range selection, the API processes all rows in the selected sheet by default. This makes it possible to integrate document generation into automation workflows and back-end applications that need to produce documents automatically.

Feature Comparison

With both workflows covered, here is a closer look at how Word and DocuGenerate handle specific features that matter most in document generation workflows. You can click on each feature in the table below to jump directly to its details.

Feature	Word	DocuGenerate
Delimiters	❌ Fixed	✅ Customizable
Preview	✅ Instant in-app preview	❌ Requires generating a document
PDF export	❌ Only via manual save	✅ Yes
Bulk generation	✅ Single merged Word file	✅ Single combined file or individual files grouped in a ZIP
Dynamic filenames	❌ No	✅ Yes, using merge tags
API access	❌ No	✅ Yes
Email delivery	✅ Yes, via Outlook	❌ No, possible via automation tools
Conditions	✅ Yes, via Rules	✅ Yes, including enhanced expressions
Images	✅ Local files only	✅ By URL or Base64, with size control
QR codes and barcodes	✅ Yes, via field codes	✅ Yes, with rendering options
Append PDF	❌ No	✅ Yes

Delimiters

Word requires the «» guillemet characters as merge field delimiters. These are inserted through the Word interface and cannot be typed or changed to another format. DocuGenerate lets you set any delimiters in the template settings, making it easy to migrate an existing Word template or match a format your team already uses.

Preview

Word’s Preview Results button shows the populated document instantly, which makes it easy to iterate on the template during development without generating a file every time. DocuGenerate does not have an equivalent in-app preview. To see the output, you generate a document. For templates under active development, this adds a small feedback loop compared to Word, though the generated file is typically available in a few seconds.

PDF export

Word’s mail merge produces a Word document as its primary output. Converting to PDF requires saving or exporting the file separately, and the process does not create individual PDF files per record automatically. DocuGenerate can generate both DOCX and PDF output directly.

Bulk Generation

Both tools support generating multiple documents from a spreadsheet in one pass. Word assembles all merged records into a single Word file with page breaks between records. DocuGenerate gives you more control: you can combine all documents into a single output file or produce individual files grouped in a ZIP archive.

Dynamic Filenames

Word does not support dynamic filenames for merged output. DocuGenerate lets you use merge tags in the document name, so each generated file can be named using values from the data row, such as the employee’s full name or contract start date. This makes the output immediately organized without any manual renaming after the merge.

API Access

Word mail merge has no API and cannot be triggered from outside the Word application. DocuGenerate provides a REST API that integrates with external systems, making it possible to generate documents programmatically as part of a back-end application, or an automation platform.

Email Delivery

Word supports sending merged documents as individual email messages directly through Outlook, which is useful for bulk outreach or internal communications. DocuGenerate does not have built-in email delivery, but it can be combined with email tools through automation platforms like Zapier, Make, n8n, or Power Automate to achieve the same result as part of a larger workflow.

Conditions

Both tools support conditional content inside templates. Word provides Rules such as IF...THEN...ELSE, available under Mailings > Rules , which let you show or hide content based on field values. DocuGenerate uses a condition tag syntax written directly in the template body. With enhanced syntax enabled, DocuGenerate also supports logical expressions, comparisons, and arithmetic in conditions, which goes beyond the rule set available in Word.

Images

Word allows dynamic images in mail merge, but the images must be stored locally on the machine running the merge and configured through field codes, which makes the setup difficult to reproduce or automate. DocuGenerate supports images referenced by URL or Base64, which works reliably in cloud-based workflows where images are hosted externally. You can also control image dimensions directly in the merge tag using the size filter, making layout control straightforward without touching the document structure.

QR Codes and Barcodes

Word supports barcodes and QR codes via the MergeBarCode and DisplayBarcode field codes, though the syntax is not straightforward and visual customization options are limited. DocuGenerate has a dedicated QR code and barcode syntax that converts any field value into a QR code or barcode with configurable dimensions, colors, and formatting directly from the merge tag.

Append PDF

Word does not natively support appending additional PDF content to a merged output file. DocuGenerate lets you append a static PDF file at the end of each generated document, which is useful for contracts that need to include standard terms and conditions, legal notices, or fixed annexes as part of every output.

Conclusion

For teams that work entirely within the Microsoft 365 desktop environment and need to produce merged documents without involving any external systems, Word’s built-in mail merge covers the basics well. It handles field substitution, conditional rules, and direct email delivery through Outlook, all without requiring a separate tool.

DocuGenerate is a better fit when document generation needs to participate in a larger workflow. Its API makes it usable from automation platforms, back-end systems, and no-code tools, and features like PDF output, dynamic filenames, and PDF appending cover scenarios that Word mail merge cannot address natively. For teams already using Word to design templates, the transition is minimal because the templates have the same format.

The choice between the two comes down to where the generation step sits in your process. If it is a one-off task performed on a desktop, Word is already available and sufficient. If it is a recurring, automated step in a business workflow, a dedicated tool like DocuGenerate provides the flexibility to connect document generation to your existing systems.

Resources

The Employment Contract.docx Word template used in this article.
The Employment Contract.xlsx sample data file.
The Employment Contract Merged.docx merged output from Word.
The Employment Contracts.zip with dynamic filenames from DocuGenerate.
Microsoft’s documentation on mail merge for letters and bulk documents.
Microsoft’s guide on using an Excel spreadsheet as a mail merge data source.

Generate Property Listings with n8n and DocuGenerate

DocuGenerate — Fri, 13 Mar 2026 00:00:00 +0000

Introduction

Real estate agencies and property management companies regularly produce listing documents for new properties, whether for print, email campaigns, or client portals. Assembling these documents manually, from gathering agent details and writing descriptions to sourcing photos and formatting everything consistently, takes time that could be spent elsewhere. In this tutorial, we’ll build an automated workflow using n8n, Claude, and DocuGenerate that produces a polished, ready-to-share property listing PDF in a matter of seconds.

The workflow uses the Anthropic node in n8n, which calls Claude to generate realistic listing data on demand, and merges it into a professionally designed Word template via DocuGenerate. The finished PDF is then downloaded and saved directly to a Dropbox folder. While this tutorial uses Claude to simulate data input, the same workflow can be connected to any real data source: a web form, a CRM, a property database, or a spreadsheet. The document generation and delivery steps remain identical regardless of where the data comes from, making this a solid foundation for real-world automation. By the end of this guide, you’ll have a fully functional n8n workflow that you can import and adapt to your own use case.

Setting Up the Property Listing Template

Before building the n8n workflow, we need a document template in DocuGenerate. For this tutorial, we’ll use the Property Listing Word template, which features a clean real estate layout with a large hero image at the top, a row of three interior photos, key property details, a QR code linking to the listing page, and an agent card at the bottom.

The template uses the following merge tags:

agent_photo, agent_name, agent_email, agent_phone, agent_address: Agent contact details displayed in the footer card.
price: Displayed prominently next to the heading.
surface, bedrooms, bathrooms, kitchens: Key property stats shown in the details row.
description: A short paragraph describing the property, displayed below the headline section.
main_image, image1, image2, image3: Property photos embedded in the layout.
url: Converted into a QR code displayed in the top-right corner of the document.

Several features of this template are worth highlighting in more detail:

Image sizing. The hero image uses the [%main_image | size:'auto':600] size syntax to constrain its height to 600 pixels while preserving the aspect ratio. The three interior photos use [%image1 | size:240:'auto'] to fix their width at 240 pixels, keeping all three images the same size and aligned in a row. Images can be passed as either a public URL or a base64-encoded data URI.
QR code. The url field is not displayed as plain text. Instead, the template uses the [%url | qrcode:60:60 | set:'barcolor':'#2f7498'] syntax to render the value as a QR code with custom dimensions and a brand color matching the document theme. Scanning the code in the generated PDF takes the reader directly to the property listing page online.
Pluralization. The stats row uses conditional syntax to handle pluralization automatically. For example, the bedroom count is written as [bedrooms] Bedroom[#bedrooms > 1]s[/] in the template, which outputs “1 Bedroom” or “3 Bedrooms” depending on the value of the bedrooms field. The same pattern applies to bathrooms and kitchens.

All three of these features rely on DocuGenerate’s enhanced syntax, which must be enabled for the template before generating documents. You can turn it on in the template settings in the web app.

The n8n Workflow Overview

In this workflow, we’ll use Claude to generate dummy listing data so the process can be demonstrated end-to-end without requiring a live database or external system. In a real deployment, the manual trigger and Message a model node would be replaced by a trigger and data source that reflects your actual process.

The complete workflow consists of several nodes connected in a linear sequence:

You can download the workflow JSON file and import it directly into your n8n instance. You’ll need to update the DocuGenerate template ID, your API credentials, and the Dropbox destination path to match your own setup. Let’s go through each node in detail.

Generating Listing Data with Claude

The first functional node is the Message a model node from the Anthropic integration, configured to use the claude-sonnet-4-6 model. Its role in this workflow is to produce a realistic set of property listing values that can be passed to DocuGenerate. To use this node, you’ll need an Anthropic account and an API Key generated from the Anthropic Console, which you add as a credential in n8n when setting up the node for the first time.

The prompt includes the full JSON structure that the template expects, with most fields left empty for Claude to fill in. The agent_photo field is pre-filled with a URL pattern from randomuser.me, a free service that returns a realistic portrait photo for a given numeric ID. Claude is instructed to replace <AGENT_ID> with a random integer between 1 and 50, producing a different agent photo on each run.

Here is the full prompt used in the node:

Can you generate dummy values for the following JSON? The <AGENT_ID> needs to be an integer from 1 to 50.
The description needs to be around 400 characters. The output needs to be just the updated JSON.

{
  "agent_photo": "https://randomuser.me/api/portraits/women/<AGENT_ID>.jpg",
  "agent_address": "",
  "agent_phone": "",
  "agent_email": "",
  "agent_name": "",
  "description": "",
  "kitchens": "",
  "bathrooms": "",
  "bedrooms": "",
  "surface": "",
  "price": "",
  "url": "https://www.docugenerate.com/blog/generate-property-listings-with-n8n-and-docugenerate/",
  "main_image": "https://images.pexels.com/photos/1571459/pexels-photo-1571459.jpeg",
  "image1": "https://images.pexels.com/photos/2062431/pexels-photo-2062431.jpeg?w=400",
  "image2": "https://images.pexels.com/photos/2089698/pexels-photo-2089698.jpeg?w=400",
  "image3": "https://images.pexels.com/photos/164595/pexels-photo-164595.jpeg?w=400"
}

The four image fields are left as static Pexels URLs for simplicity. In a real-world scenario, these would be actual photos of the property fetched from a media library, a CRM attachment, or a cloud storage bucket. The url field points to this blog post and will be rendered as a QR code in the final document.

Claude returns the completed JSON wrapped in a markdown code block. The response from the Message a model node has the following structure:

[
  {
    "content": [
      {
        "type": "text",
        "text": "```

json\n{\n \"agent_name\": \"Sarah Mitchell\",\n \"price\": \"$485,000\",\n ...\n}\n

```"
      }
    ]
  }
]

The actual listing data is nested inside content[0].text and wrapped in markdown fences, which means it cannot be used directly by the next node. That is what the Code node in the following step handles.

Parsing the Claude Response

The Code in JavaScript node extracts the JSON object from Claude’s response and exposes it as clean, structured data for the rest of the workflow. This step is necessary for two reasons: the Message a model node returns the full API response object rather than just the text content, and Claude tends to wrap its JSON output in markdown code fences even when instructed not to. Rather than relying on prompt engineering to fix this inconsistency, the Code node handles it reliably every time.

const text = $input.first().json.content[0].text;
const json = text.replace(/```
{% endraw %}
json\n?/, '').replace(/\n?
{% raw %}
```/, '').trim();
return { json: JSON.parse(json) };

The first line reads the text value from Claude’s response. The second line strips the markdown code fences using two regular expressions. The third line parses the cleaned string into a JavaScript object and returns it as the node output. After this step, all the listing fields (agent_name, price, bedrooms, etc.) are available as top-level keys in the item’s JSON, ready to be passed directly to DocuGenerate.

Generating the Document

The Generate document node uses the DocuGenerate integration for n8n to merge the listing data with the Word template and produce a PDF. To use this node, install DocuGenerate in your n8n instance and configure it with your API Key.

The node is configured with the following parameters:

Template Name or ID : The Property Listing template uploaded in the template setup step.
Name : An n8n expression that generates a dynamic document name: Property Listing for {{ $json.price }} ({{ $json.surface }}). This produces a filename like Property Listing for $485,000 (1,850 sq ft) that makes each document easy to identify.
Format : Set to PDF (.pdf).
Data : Set to {{ $json }}, which passes the entire output of the Code node as the data payload. Since the Code node already produces a flat JSON object with all the template fields at the top level, no additional mapping is needed.

When the node runs successfully, the response contains, among others, a document_uri field with a URL pointing to the generated PDF, and a filename field with the document’s filename.

Downloading the Generated PDF

DocuGenerate returns a URL to the generated document rather than the binary file content directly. To upload the PDF to Dropbox in the next step, we first need to fetch the file from that URL. The HTTP Request node handles this by making a GET request to the document_uri returned by the Generate document node.

The URL parameter is set to {{ $json.document_uri }}, referencing the document URL from the previous step. The binary file data is then available to the Dropbox node for upload.

Saving the PDF to Dropbox

The final node uploads the generated PDF to a designated Dropbox folder using the Dropbox node in n8n, giving the team immediate access to the new listing document.

The node uses OAuth2 authentication connected to your Dropbox account. The File Path parameter is set to /n8n/Property Listings/{{ $json.filename }}, saving each document in the /n8n/Property Listings/ folder using the filename returned by DocuGenerate. The Binary File option is enabled so the node reads the file content from the HTTP Request node’s output rather than a static path.

Once the workflow completes, the generated PDF is available in Dropbox and looks like this. You can also download a sample PDF to see the final result.

Real-World Data Sources

The current workflow uses Claude as a convenient stand-in for a real data source, but in practice, property listing data rarely comes from an AI model. It typically lives in a form submission, a CRM record, a database row, or a spreadsheet. Since the document generation and delivery steps stay the same regardless of where the data originates, swapping out the Anthropic node for a different trigger and data source is all it takes to turn this tutorial workflow into a production-ready automation. Below are some common scenarios this workflow is well-suited for.

Web Forms

Many agencies use online forms to collect property details from listing agents before preparing marketing materials. A form tool like Jotform, Typeform, or Tally can capture fields such as address, price, number of rooms, surface area, and a description directly from the agent. When a new submission arrives, the form platform can trigger the n8n workflow via a webhook, passing all collected data straight into the document generation step. This makes property listing creation a natural follow-up to the intake process, with no manual data transfer required.

CRM Systems

Real estate businesses that manage their inventory in a CRM such as Salesforce, HubSpot, or Pipedrive can trigger document generation whenever a property record reaches a certain pipeline stage, for example when it is marked as “Ready to publish” or “New listing”. The workflow would pull the relevant fields from the CRM record, merge them into the template, and either save the PDF back to the record or deliver it to the assigned agent by email. This keeps the listing document in sync with the CRM data and eliminates duplicate data entry.

Databases and Spreadsheets

Teams that manage their property inventory in a database such as PostgreSQL, Airtable, or Notion, or in a spreadsheet like Google Sheets or Excel, can query new or updated records on a schedule or in response to a row being added. n8n has native nodes for all of these platforms, making it straightforward to read a row, map the columns to the template fields, and generate a PDF for each property. This approach works particularly well for agencies that add multiple listings at once and want to generate all documents in a single automated run.

Conclusion

In this tutorial, we built an n8n workflow that generates a property listing PDF automatically. The workflow uses Claude to simulate a realistic data input, parses the response into structured JSON, merges the data with a professionally designed Word template, and saves the resulting PDF to Dropbox. The template demonstrates several advanced DocuGenerate features including image sizing with filters, QR code generation, and automatic pluralization via conditional syntax.

In a real deployment, the Anthropic node would be replaced by a connection to your actual data source, whether that is a web form, a CRM, a database, or a spreadsheet. The document generation and delivery steps remain the same, making this workflow straightforward to adapt to almost any property management setup.

Resources

The Property Listing Word template.
The workflow JSON file that you can import into your n8n instance.
A sample generated PDF showing the final output.
The DocuGenerate integration guide for n8n.
Photos provided by Pexels for the property images.

How to Generate Business Letters in Coda with DocuGenerate

DocuGenerate — Wed, 25 Feb 2026 00:00:00 +0000

Introduction

Business letters are a staple of professional communication, whether you’re sending client proposals, formal notifications, or outreach campaigns. Writing each letter individually is repetitive and error-prone, and the problem compounds quickly when you have a long list of recipients. In this tutorial, we’ll show how to use Coda and DocuGenerate together to generate personalized PDF business letters directly from a table, with a single button click per row.

Coda is a flexible workspace that combines documents and spreadsheets into a single platform, making it easy to build interactive tools with tables, buttons, and custom formulas. The DocuGenerate Pack extends Coda with document generation capabilities, letting you produce professional PDFs from Word templates without writing any code. Each row in a Coda table becomes a personalized document, populated with the values from that row’s columns.

By the end of this guide, you’ll have a Coda document with a table of recipients and a Generate button that produces a personalized PDF business letter for each person. The generated files are saved directly into a PDF column in the table, ready to be downloaded or shared.

Setting Up the Business Letter Template

Before working in Coda, we need a document template in DocuGenerate. We’ll use the Business Letter Word file from our Template Library, which is a professionally formatted letter ready for immediate use.

The template contains merge tags for Date, Name, Job Title, Company Name, Street Address, City, State, Zip Code, Email, and Phone. These tags act as placeholders that get replaced with actual data when a document is generated.

Once you’ve downloaded the Word file, upload it to your DocuGenerate account to create a new template. The merge tags will be detected automatically, and you can preview the result on the template page before moving on.

Importing the Data into Coda

The Business Letter template in the Template Library comes with a matching Excel dataset that contains sample recipient data aligned with all the template’s merge tags. Each row represents one recipient, and each column maps directly to one of the merge tags in the letter.

To bring this data into Coda, open the Business Letter.xlsx file in Excel or any spreadsheet application, select the entire table including the header row, and copy it. Then open your Coda document, click in an empty area of the page, and paste. Coda will recognize the tabular structure and create a new table from the clipboard data automatically, preserving all column names and values.

Adding the Generate and PDF Columns

With the data in place, we need to add two columns to the table: one for the generate button and one for storing the output file. Click the + icon at the end of the table header row to add the first new column.

Select Button as the column type, then choose New to create a blank button configuration. Once the column appears, rename it to Generate.

Repeat the same process to add a second column. This time, select File as the column type and rename the column to PDF. This column will hold the generated PDF file for each row after the button is clicked.

The table should now display all the original data columns along with the two new ones at the end.

Installing the DocuGenerate Pack

To connect the table to DocuGenerate, we need to add the DocuGenerate Pack to the Coda document. Click Insert in the top-right corner of the Coda editor and search for DocuGenerate in the Packs search box.

Select DocuGenerate from the results and click Add to doc for free to install the Pack.

Once installed, the Pack’s building blocks will become available in your document: the Templates table, the Documents table, the Generate Document button action, and the DataStructure formula.

To complete the setup, open the Settings tab next to Building blocks , click Select an account , and then Add a new account. Enter your API Key from your DocuGenerate account in the API token field and click Continue. Your DocuGenerate account is now connected and the Pack is ready to use.

Configuring the Generate Document Button

With the Pack installed, we can configure the Generate column to call DocuGenerate when clicked. Click the column header menu for the Generate column and select Edit column.

In the On click action section, scroll down to the Packs category at the bottom of the action list, find DocuGenerate , and select the Generate Document action.

Click + Connect an account and select the DocuGenerate account you configured in the previous section. With the account connected, you can now fill in the action parameters.

Template Selection

From the Template dropdown, select the Business Letter template you uploaded to DocuGenerate in the template setup step.

Document Name and Format

For the Name field, you can leave it empty to use a default name, or set a dynamic value to make it easier to identify each file. Coda’s Format formula is a good fit here. For example, =Format("Letter for {1}", thisRow.Name) names each document after the recipient.

Leave Format set to .pdf to produce PDF files, which is the most commonly used format for sharing documents.

Dynamic Data Values

For the Data field, we need to provide a JSON object that maps the merge tag names in the template to the corresponding column values in the current row. Coda’s Object formula is the most direct way to build this mapping:

Object(
  "Name", thisRow.Name,
  "Job Title", thisRow.[Job Title],
  "Company Name", thisRow.[Company Name],
  "Street Address", thisRow.[Street Address],
  "City", thisRow.City,
  "State", thisRow.State,
  "Zip Code", thisRow.[Zip Code],
  "Email", thisRow.Email,
  "Phone", thisRow.Phone,
  "Date", thisRow.Date
)

Each key in the Object call is a merge tag name from the template, and each value references the matching column in the current row using thisRow. Column names that contain spaces must be wrapped in square brackets, as shown with thisRow.[Job Title] and thisRow.[Company Name].

For templates with more complex or nested data, the DataStructure formula included with the DocuGenerate Pack is a useful alternative. It generates the expected JSON structure for any template automatically, with numbered placeholders that you can fill in using the Format formula.

Result PDF Column

Finally, set the Results column to the PDF column added earlier. This instructs Coda to store the generated file in that column after the button is clicked. You can also customize the button’s appearance in the Style section by setting a label, choosing a color, and picking an icon.

Generating the Documents

With the configuration complete, click the Generate button in any row to trigger document generation for that recipient. DocuGenerate will use the row’s data to fill in the merge tags in the template and return a PDF file. Coda then imports the file into its storage and displays it in the PDF column for that row. The entire process takes a few seconds, so expect a brief delay before the file appears.

You can click Generate for multiple rows in quick succession without waiting for each document to finish. DocuGenerate processes the requests concurrently, so all documents are generated in parallel. The number of documents you can process at the same time depends on your plan’s concurrent documents limit.

Conclusion

In this tutorial, we built a Coda document that generates personalized PDF business letters from a table of recipient data using the DocuGenerate Pack. The workflow covers uploading a Word template to DocuGenerate, importing the recipient data into Coda, adding the Generate button and PDF columns, and wiring up the Generate Document action to map data from each row to the template’s merge tags. Once the setup is in place, generating a letter for any recipient takes a single button click.

The same pattern applies to any document type you want to produce from tabular Coda data. Invoices, contracts, offer letters, and certificates all follow the same structure: a Word template with merge tags, a table with the corresponding data, and a button to trigger the process. You can extend this further by combining it with other Coda automations, such as generating documents automatically when a new row is added, or sending the generated files to recipients via email.

Resources

The Business Letter Word template and Excel dataset used in this tutorial.
The DocuGenerate Pack on Coda for adding document generation to your Coda docs.
The Coda integration guide in the Help Center, including setup instructions and formula references.
Official Coda formula reference for formulas used in this tutorial.

Automate PDF Certificate Generation with FlowRunner

DocuGenerate — Wed, 21 Jan 2026 00:00:00 +0000

Introduction

Certificates are a common output in many business processes, from training completion records to achievement awards and event participation confirmations. Manually creating individual certificates for each recipient is tedious and error-prone, especially when dealing with dozens or hundreds of records. In this tutorial, we’ll build an automated workflow using FlowRunner and DocuGenerate that generates PDF certificates every time a new record is added to a database table.

FlowRunner is part of the Backendless platform and makes it easy to create intelligent workflows with just a few clicks. It orchestrates automated workflows that combine AI agents, human decision-making, and system integrations. Both technical and non-technical users can build workflows. Non-technical users work through the visual interface while technical users can leverage custom code and advanced integrations.

The workflow we’ll create listens for new records in a Backendless database table, generates a personalized PDF certificate using DocuGenerate, saves the generated file in the Backendless File Service, and updates the original database record with a link to the PDF file. By the end of this guide, you’ll have a fully functional certificate automation pipeline that you can adapt for any document type.

Setting Up the Certificate Template

Before building the FlowRunner workflow, we need to prepare the certificate template in DocuGenerate. To keep things simple, we’ll use the ready-made Certificate of Achievement from our Template Library. This is a standard certificate layout with merge tags for Company Name, Name, Course Name, Diploma Title, and Certificate Date. You can customize the template by modifying the design, adjusting the layout, or adding other merge tags to match your organization’s branding and requirements.

Once you’ve downloaded the template file, upload it to your DocuGenerate account. After the upload is complete, take note of the template ID displayed on the template page, as you’ll need it when configuring the document generation step in the workflow.

Creating the Participants Table

Next, we need a database table in Backendless to store the data used for generating certificates. Navigate to the Database section of your Backendless app and create a new table called Participants.

Add the following columns to the table:

Certificate Date (DATETIME): The date to be printed on the certificate.
Certificate URL (STRING): Stores the URL of the generated certificate file. This column will be populated automatically by the workflow.
Company Name (STRING): The name of the company or organization issuing the certificate.
Course Name (STRING): The name of the course or program the participant completed.
Diploma Title (STRING): The title of the diploma or achievement being awarded.
Name (STRING): The participant’s full name.

The Certificate URL column starts empty for each new record. The workflow will fill it in automatically with the URL of the generated PDF after the entire flow completes, providing a direct link back to the certificate from the database.

Configuring the Database Trigger

With the table in place, head over to the FlowRunner Designer page and create a new flow called “Certificate of Achievement Flow”. The first element we need is a trigger that starts the flow whenever a new participant record is created. In the Triggers panel, select the Record Created in Database trigger from the Data Service category.

The trigger configuration is straightforward. Select the Participants table in the Table or View dropdown and set Reference Trigger Data As to Participant. You can leave all other fields at their default values.

This means that every time a new row is inserted into the Participants table, the flow will execute and the record data will be accessible as the Participant object throughout the remaining steps.

Generating the Document

With the trigger in place, we can add the document generation step. Find the DocuGenerate extension and select the Generate Document action. This action will execute every time the trigger fires, generating a new certificate based on the participant’s data.

Configure the action with the following parameters:

Template ID : The ID of the template you uploaded to DocuGenerate in the earlier step.
Name : Use the Expression input to create a dynamic name by concatenating the text Certificate for with the Participant -> Name value.
Output Name : Leave empty, the generated file will use the document name.
Output Format : Set to .pdf to produce a PDF file.
Data : Use the Expression input to construct the JSON data object (explained below).

Finally, set Reference Result Data As to Document and leave the remaining parameters unchanged.

The Data parameter requires a JSON array that maps each merge tag in the template to the corresponding value from the Participant record. FlowRunner’s Expression input lets you combine static text with dynamic block results to construct this JSON at runtime. You alternate between Text Inputs (for the JSON structure and key names) and Block Results (to reference the Participant object’s properties). The resulting expression produces a value equivalent to:

[{
  "Company Name": "Participant -> Company Name",
  "Name": "Participant -> Name",
  "Course Name": "Participant -> Course Name",
  "Diploma Title": "Participant -> Diploma Title",
  "Certificate Date": "Participant -> Certificate Date"
}]

The screenshot below shows the Expression input with all the text and reference blocks assembled. Each key in the JSON object corresponds to a merge tag in the certificate template, and each value is dynamically pulled from the participant’s database record.

Saving the File to Backendless

Now that the document generation step is configured, we can continue building the workflow by saving the generated PDF certificate to the Backendless File Service. In the Extensions panel, go to Backendless File Services and select the Add To File action. This action appends content to an existing file, and can also create a new file from a remote URL using the Content From URL field.

Configure the action with the following body parameters:

Directory Path : Set to certificates to save all generated files in a dedicated folder.
File Name : Use the expression Document -> filename to name the file based on the document generated in the previous step.
Content From URL : Use Document -> document_uri to download the generated PDF from DocuGenerate.

Don’t forget to set Reference Result Data As to File. The File object will contain a fileURL property that we’ll use in the next step to store the file’s location back in the database.

Updating the Database Record

For the final step of the workflow, we need to update the original Participants record with the URL of the saved certificate. This creates a direct link between each participant’s database entry and their generated certificate, making it easy to retrieve or display the file later, whether from a web application, a report, or directly from the database table.

In the Actions panel, go to Data Service and select the Save Record In Database action. This action stores or updates data in your Backendless database when executed and can be placed at any point in the workflow to ensure timely data updates in response to specific events or actions.

To configure the action, select the Update record from flow option and choose Use data from the Participant object. In the Perform Changes section, select the Certificate URL property and enter the File -> fileURL value. This writes the URL of the file we saved in the previous step back into the participant’s record. Optionally, you can set the Reference Result Data As to Record.

Testing the Workflow

With all four steps in place, the workflow is complete and ready for an end-to-end test. The flow follows a clear sequence: a new database record triggers document generation, the generated PDF is saved to Backendless file storage, and the record is updated with the file URL.

To start the flow, click the Play button in the FlowRunner Designer. Note that once a flow is running, you cannot make changes to it, but you can stop it at any time and update the configuration if needed.

There are multiple ways to test the workflow, and one of the easiest ways is to use the REST Console in the Participants table. For example, we can run a POST request with the following request body:

{
  "Company Name": "Wikivu",
  "Name": "Brandtr Lusk",
  "Course Name": "Property-Casualty Insurers",
  "Diploma Title": "Food Chemist",
  "Certificate Date": "7/12/2024"
}

The response body confirms that a new record has been created in the database. Within moments, the workflow executes and generates the certificate.

As expected, the generated PDF certificate appears in the certificates folder in the File Service. As a future improvement, you could also delete the document from DocuGenerate after saving it to Backendless, keeping your DocuGenerate account tidy.

In the Participants table, the Certificate URL column now contains a link to the file stored in the Backendless file storage, confirming that the entire flow works correctly from trigger to completion.

If you’d like to try this workflow yourself, you can download the complete flow definition and import it into your FlowRunner instance. You’ll need to update the template ID and table references to match your own Backendless app configuration.

Conclusion

In this tutorial, we built a complete certificate automation workflow using FlowRunner and DocuGenerate. The flow listens for new records in a Backendless database, generates a personalized PDF certificate for each participant, saves the file to the Backendless File Service, and updates the database record with a link to the generated document. The entire process runs automatically without any manual intervention once the flow is started.

This workflow demonstrates one practical example of what you can build with FlowRunner and DocuGenerate. The same pattern applies to any scenario where you need to generate documents from database records, such as invoices, contracts, reports, or any other templated document. You could also extend this workflow by adding email notifications, conditional branching based on record data, or integrations with other services available in the Backendless ecosystem.

Resources

The Certificate of Achievement template used in this tutorial.
The DocuGenerate integration guide for Backendless.
The complete flow definition that you can import and use.
The DocuGenerate extension on FlowRunner.
Official FlowRunner documentation.

Generate Health Plan Proposals in Power Apps with DocuGenerate

DocuGenerate — Mon, 22 Dec 2025 00:00:00 +0000

Introduction

Employee onboarding often involves helping new hires navigate complex benefit options, particularly when it comes to selecting health insurance plans. Companies typically offer multiple health plans with varying coverage levels, premiums, and out-of-pocket costs, which can overwhelm new employees trying to make the best decision for their families. In this tutorial, we’ll take an existing Power Apps Health Plan Selector app and enhance it with automated document generation capabilities using DocuGenerate and Power Automate.

The Health Plan Selector is a sample application that helps new employees explore company health plans through a series of guided questions. Based on the answers, the app recommends the most suitable plan. However, the original app simply sends the plan details via the user’s default email client. We’ll replace this basic functionality with an automated workflow that generates a professional PDF proposal and delivers it directly to the employee’s inbox without requiring any manual email composition.

This approach creates a better experience for both HR teams and new employees. The automated workflow ensures consistency in how plan information is presented, creates a formal document that employees can review at their leisure and discuss with family members, and eliminates the manual steps involved in composing and sending these communications. Throughout this guide, we’ll walk through each step of the integration, from understanding the existing app structure to creating a complete document generation workflow.

Starting with the Health Plan Selector Template

Power Apps provides a variety of ready-to-use templates that serve as excellent starting points for building business applications. For this tutorial, we’ll use the Health Plan Selector template, which demonstrates many key Power Apps concepts including user input validation, conditional logic, multi-screen navigation, and data collection.

To get started, open Power Apps and click on Start with an app template. This option allows you to select from a list of fully functional business app templates that you can use as-is or customize to suit your specific needs. Browse through the available templates until you find the Health Plan Selector app. This sample app is designed specifically for new employee onboarding scenarios, helping users explore company health plans and discover which option will work best for them and their families.

Once you select this template, Power Apps will create a new app in your environment based on the template structure. The app includes all the screens, controls, data collections, and logic needed for the health plan selection workflow. You’ll be able to explore and modify any aspect of the app to fit your organization’s specific health plan offerings and branding guidelines.

Understanding the Sample App

The Health Plan Selector app guides users through a multi-step questionnaire to determine the most appropriate health insurance plan. The app asks about coverage needs (individual, family, etc.), desired services (primary care, dental, vision, specialists), budget preferences (basic or premium), and other factors that influence plan selection. Based on these inputs, the app recommends specific plans and displays detailed information including monthly premiums, coverage limits, and out-of-pocket costs.

The app is built with multiple screens that represent different stages of the selection process. After creating the app from the template, you can view all screens in the Tree view panel, which shows screens like HomeScreen, Step1_Screen, Step2_Screen, Step3_Screen, Step4_Screen, Recommendation_Screen, ViewOptions_Screen, and Share_Screen.

Each screen contains various controls such as text inputs, radio buttons, checkboxes, galleries, and buttons that work together to collect user preferences and display recommendations.

Examining the Send Button Logic

For this tutorial, we’ll focus specifically on the Share_Screen, which is where users see their final plan recommendation and have the option to send the details to their email address. This is the screen we’ll modify to integrate document generation capabilities instead of the basic email functionality that currently exists.

The Share_Screen includes a SEND button that currently triggers a mailto link to compose an email with the plan details. To understand what we need to replace, let’s examine the existing button logic. When you select the SEND button in the app designer, you can view its associated code in the formula bar.

The code uses the Launch function to open the user’s default email client with pre-populated subject and body content. This approach has several limitations. It requires the user to have a default email client configured, it opens the email in draft form requiring the user to manually click send, and the formatting is limited to plain text with URL-encoded line breaks.

The code also performs data collection operations to store the user’s responses in a collection called ResponsesCollect. Here’s the complete code from the original SEND button:

If(!IsBlank(TextInput1_1.Text);Collect(ResponsesCollect;{QuestionId:"1";ResponseId:Text(CountRows(ResponsesCollect)+1);Response:Radio1.SelectedText.OptionText});;

If(CountRows(BasicCollect)>=1;Collect(ResponsesCollect;{QuestionId:"2";ResponseId:Text(CountRows(ResponsesCollect)+1);Response:Text(Last(FirstN(BasicCollect;1)).OptionText)}));;

If(CountRows(BasicCollect)>=2;Collect(ResponsesCollect;{QuestionId:"2";ResponseId:Text(CountRows(ResponsesCollect)+1);Response:Text(Last(FirstN(BasicCollect;2)).OptionText)}));;

If(CountRows(BasicCollect)>=3;Collect(ResponsesCollect;{QuestionId:"3";ResponseId:Text(CountRows(ResponsesCollect)+1);Response:Text(Last(FirstN(BasicCollect;3)).OptionText)}));;If(CountRows(BasicCollect)>=4;Collect(ResponsesCollect;{QuestionId:"4";ResponseId:Text(CountRows(ResponsesCollect)+1);Response:Text(Last(FirstN(BasicCollect;4)).OptionText)}));;

If(CountRows(BasicCollect)>=5;Collect(ResponsesCollect;{QuestionId:"2";ResponseId:Text(CountRows(ResponsesCollect)+1);Response:Text(Last(FirstN(BasicCollect;5)).OptionText)}));;

If(CountRows(AddONCollect)>=1;Collect(ResponsesCollect;{QuestionId:"2";ResponseId:Text(CountRows(ResponsesCollect)+1);Response:Text(Last(FirstN(AddONCollect;1)).OptionText)}));;If(CountRows(AddONCollect)>=2;Collect(ResponsesCollect;{QuestionId:"2";ResponseId:Text(CountRows(ResponsesCollect)+1);Response:Text(Last(FirstN(AddONCollect;2)).OptionText)}));;

If(CountRows(AddONCollect)>=3;Collect(ResponsesCollect;{QuestionId:"2";ResponseId:Text(CountRows(ResponsesCollect)+1);Response:Text(Last(FirstN(AddONCollect;3)).OptionText)}));;

If(CountRows(AddONCollect)>=4;Collect(ResponsesCollect;{QuestionId:"2";ResponseId:Text(CountRows(ResponsesCollect)+1);Response:Text(Last(FirstN(AddONCollect;4)).OptionText)}));;

If(CountRows(AddONCollect)>=5;Collect(ResponsesCollect;{QuestionId:"2";ResponseId:Text(CountRows(ResponsesCollect)+1);Response:Text(Last(FirstN(AddONCollect;5)).OptionText)}));;

If(CountRows(AddONCollect)>=6;Collect(ResponsesCollect;{QuestionId:"2";ResponseId:Text(CountRows(ResponsesCollect)+1);Response:Text(Last(FirstN(AddONCollect;6)).OptionText)}));;

Collect(ResponsesCollect;{QuestionId:"3";ResponseId:Text(CountRows(ResponsesCollect)+1);Response:Radio1_2.SelectedText.OptionText});;

Collect(ResponsesCollect;{QuestionId:"4";ResponseId:Text(CountRows(ResponsesCollect)+1);Response:Radio1_3.SelectedText.OptionText});;

Launch("mailto:"&TextInput1_1.Text&"?subject="&TextBox1_16.Text&" &body=Plan Details:" &TextBox1_16.Text& "%0D%0A" & TextBox3_5.Text & "%0D%0A" &TextBox3_6.Text & "%0D%0A" & TextBox3_7.Text & "%0D%0A" &TextBox3_8.Text& "%0D%0A" & EncodeUrl(TextBox3_9.Text) & "%0D%0A" & EncodeUrl(TextBox3_11.Text));;

Navigate(Screen1;ScreenTransition.Fade);UpdateContext({emailreset:true}));;

This code collects response data from various form controls and collections, then constructs a mailto URL with the email address from TextInput1_1.Text, the plan name from TextBox1_16.Text as the subject, and several other text box values concatenated into the body. We’ll replace the Launch function call with a call to a Power Automate flow that handles document generation and email delivery.

Modifying the Button to Call Power Automate

Instead of launching the email client, we’ll modify the SEND button to trigger a Power Automate flow. This flow will receive the plan details, generate a professional PDF document using DocuGenerate, and send it via email. Replace the entire Launch function call with the following code:


SendEmailWithDocument.Run(TextInput1_1.Text; TextBox1_16.Text; TextBox3_5.Text; TextBox3_6.Text; TextBox3_7.Text; TextBox3_8.Text; TextBox3_9.Text; TextBox3_11.Text; User().FullName);;

This modified code calls a Power Automate flow named SendEmailWithDocument and passes nine parameters: the email address, plan name, coverage details, price per month, price per individual, out-of-pocket limit, coinsurance percentage, additional services, and the current user’s full name.

The User().FullName function retrieves the authenticated user’s name from Azure Active Directory, which we can include in the personalized document. These parameters correspond to the data displayed on the Share_Screen and represent the information we want to include in the generated proposal document.

You’ll notice that Power Apps shows this flow reference in red initially because the flow doesn’t exist yet. We’ll create the flow in the next section, and once it’s connected to the app, the reference will resolve correctly.

Creating the Power Automate Flow

Now we’ll create the Power Automate flow that handles document generation and email delivery. In Power Apps, navigate to the Power Automate section from the left menu and click Create a new flow. Select Create from blank to start with an empty flow canvas.

Name your flow SendEmailWithDocument to match the flow name we referenced in the button code. The first step in any Power Apps-triggered flow is the Power Apps (V2) trigger, which defines the parameters that the app will pass to the flow.

Click Add an input for each parameter you need to receive from Power Apps. The parameter types should match the data being passed (all text in this case). The table below shows how each flow parameter maps to the corresponding UI element:

Flow Parameter	UI Element	Description
`Email`	`TextInput1_1.Text`	Recipient email address
`Plan_Name`	`TextBox1_16.Text`	Name of the recommended health plan
`Coverage`	`TextBox3_5.Text`	Coverage level description
`Price_Per_Month`	`TextBox3_6.Text`	Monthly premium amount
`Price_Per_Individual`	`TextBox3_7.Text`	Individual coverage cost
`Out_Of_Pocket_Limit`	`TextBox3_8.Text`	Maximum out-of-pocket expenses
`Coinsurance_Percentage`	`TextBox3_9.Text`	Coinsurance percentage
`Additional_Services`	`TextBox3_11.Text`	List of additional covered services
`Name`	`User().FullName`	Employee name from Azure Active Directory

Preparing the DocuGenerate Template

Before adding the document generation step to our flow, we need to create a Word template in DocuGenerate that defines the structure and formatting of our health plan proposal. The template uses merge tags that correspond to the parameter names we defined in Power Automate, which will be replaced with the actual values from the flow.

The Word document includes company branding, a clear header, sections for plan details, and additional information that should appear on every proposal. It has merge tags for all nine parameters: [Name], [Email], [Plan_Name], [Coverage], [Price_Per_Month], [Price_Per_Individual], [Out_Of_Pocket_Limit], [Coinsurance_Percentage], and [Additional_Services].

Once your template is ready, upload it to your DocuGenerate account and name it Health Plan Proposal. You can download a copy of the template used in this tutorial here.

Adding the Document Generation Step

To use DocuGenerate from Power Automate, you need to install the custom connector in your Power Platform environment. The first time you use it, you’ll need to authenticate with your DocuGenerate API Key, which you can find in your DocuGenerate account settings. This creates a connection that can be reused across multiple flows in your environment.

With the template created and the connector available, we can now add the document generation step to our flow. Click New step in your flow and search for “DocuGenerate”. Select the Generate Document action from the list of available operations.

To configure the action, select your template from the Template dropdown. If you uploaded your template with the name “Health Plan Proposal,” you should see it in the list. Next, set the Name parameter to specify what the generated document should be called. Select .pdf as the Format so that the generated document is delivered as a professional PDF rather than an editable Word file.

For the Data parameter, you need to provide a JSON object that contains all the values for the merge tags in your template. Replace each empty string with the appropriate dynamic content from the trigger step. Power Automate will display these as tokens in the expression rather than literal strings.

{
  "Name": "",
  "Email": "",
  "Plan_Name": "",
  "Coverage": "",
  "Price_Per_Month": "",
  "Price_Per_Individual": "",
  "Out_Of_Pocket_Limit": "",
  "Coinsurance_Percentage": "",
  "Additional_Services": ""
}

Sending the Email with the Document

The final step in our flow sends an email to the employee with the generated PDF proposal attached. Add a new step and search for the Send an email notification (V3) action.

Configure the email parameters as follows. Set the To field to the Email value from the Power Apps trigger, which is the address the employee entered in the app. For the Subject , use something descriptive like Your Personalized Healthcare Plan Proposal. In the Body field, compose a friendly message that explains what the attachment contains and provides any next steps the employee should take.

The most important configuration is the attachments section. This is where you connect the generated PDF to the email. For the Attachment parameter, select the document_uri output from the Generate Document step. For the Attachment File Name parameter, select the filename output from the same step. This ensures that the email includes the actual PDF document with the correct filename.

With this final step configured, save your flow and test it to ensure everything works correctly.

Testing the Complete Integration

Now that both the Power Apps app and the Power Automate flow are configured, it’s time to test the complete integration. Run the app in preview mode and go through the health plan selection process. Answer the questions about coverage needs, desired services, and budget preferences. When you reach the confirmation screen, enter your email address and click the SEND button. If everything is configured correctly, the button will trigger the Power Automate flow, which generates the PDF and sends the email.

The document contains all the plan details with the merge tags replaced by actual values from the app, and the formatting matches the professional template design.

If you encounter any issues, check the flow run history in Power Automate to see where the process might have failed. Common issues include incorrect parameter mappings, or authentication problems with any of the connectors. The flow run history provides detailed information about each step, including the data that was passed and any error messages that occurred.

Benefits of This Approach

Replacing the basic email sending functionality with automated document generation and email delivery offers several advantages for both HR teams and employees. The automated workflow ensures consistency in how health plan information is presented to all employees, eliminating variations that can occur when individuals compose emails manually. The generated PDF serves as a formal document that employees can save, print, and reference throughout the enrollment period, making it easier to compare options or discuss plans with family members.

From an operational perspective, this integration reduces the manual effort required from HR staff. Instead of having to help employees compose emails or prepare plan summaries individually, the system handles this automatically based on the recommendations generated by the app. This frees up HR time for more valuable activities like answering specific questions or helping employees with complex situations.

The approach also creates better documentation for compliance purposes. Each generated proposal is a record of what information was provided to the employee, which can be important for regulatory compliance or if questions arise later about what was communicated during the enrollment process. You could extend the workflow further by adding a step that saves each generated proposal to SharePoint or another document management system for centralized record-keeping.

Conclusion

Enhancing Power Apps applications with automated document generation capabilities demonstrates the power of the Microsoft Power Platform ecosystem when combined with specialized services like DocuGenerate. The integration we’ve built transforms a simple health plan selector app into a complete onboarding solution that guides employees through plan selection and automatically delivers professional proposal documents.

This tutorial focused on health plan proposals, but the same integration pattern can be applied to many other Power Apps scenarios. Any time your app collects data that needs to be formatted as a formal document and delivered to users or stored for records, this approach of using Power Automate to orchestrate document generation and distribution can add significant value. Whether you’re generating employment contracts, offer letters, training certificates, or custom reports, the combination of Power Apps for data collection, Power Automate for workflow orchestration, and DocuGenerate for document generation provides a powerful and flexible solution.

The no-code nature of this integration makes it accessible to business analysts and power users who may not have traditional development skills. By leveraging pre-built connectors and visual workflow designers, you can create sophisticated document automation solutions without writing custom code or managing complex infrastructure.

Resources

The Health Plan Proposal template used in this tutorial.
The DocuGenerate Guide for integrating with Power Apps.
Official Power Automate documentation from Microsoft.
Official Power Apps documentation from Microsoft.

Build a Resume Analyzer with Pipedream and DocuGenerate

DocuGenerate — Wed, 19 Nov 2025 00:00:00 +0000

Introduction

Resume screening is one of the most time-consuming aspects of the hiring process. HR teams often spend hours reviewing resumes to extract key information, evaluate candidates, and prepare summaries for hiring managers. In this tutorial, we’ll build an automated resume analyzer that handles this work for you, combining the power of Pipedream workflow automation, Claude AI for intelligent analysis, and DocuGenerate for professional PDF generation.

The workflow operates automatically whenever a new resume is added to a Dropbox folder. It extracts the text from the resume, uses Claude to analyze the candidate’s experience and qualifications, generates a structured summary with key insights, and creates a professional PDF report that your hiring team can review immediately. The entire process takes just seconds and requires no manual intervention.

This approach is particularly valuable for organizations that need to process multiple resumes quickly while maintaining consistency in candidate evaluation. By standardizing the analysis format and leveraging AI to extract insights, you can focus your time on interviewing the most promising candidates rather than spending hours on initial screening.

Understanding the Workflow

The complete workflow consists of seven connected steps that work together to transform a raw resume into a structured analysis report. Here’s how the process flows from start to finish:

The workflow begins when you upload a resume to a monitored Dropbox folder. Pipedream detects the new file, downloads it, and extracts the text content from the PDF. This text is then sent to Claude AI with specific instructions to analyze the resume and extract key information like work experience, skills, education, and notable achievements. Claude returns a structured JSON response containing all the extracted data.

The JSON data is then passed to DocuGenerate along with a pre-designed template to generate a professional PDF summary. Once the document is created, it’s automatically uploaded back to Dropbox in a designated folder where your hiring team can access it. The entire process completes in under a minute, and you can process multiple resumes simultaneously simply by uploading them to the trigger folder.

Setting Up the Document Template

Before building the Pipedream workflow, we need to create a template that will format our resume analysis reports. The template uses DocuGenerate’s merge tags syntax to define where data from Claude’s analysis should appear in the final document. This ensures every candidate summary follows a consistent, professional format.

The template includes sections for candidate information (name, email, phone, location), a professional summary, experience overview, key skills, education, strengths, interview recommendations, and an overall assessment with a fit score. Some sections like skills, strengths, and recommendations use list syntax to display multiple items from arrays in the data. For example, the skills section uses [#skills] to begin the loop, [.] to display each skill as a bullet point, and [/skills] to end the loop.

You can download the complete template and upload it to your DocuGenerate account. Once uploaded, take note of the template name or ID, as you’ll need this information when configuring the document generation step in the workflow. With the template ready, we can now build the Pipedream workflow that will automate the entire analysis process.

Configuring the Dropbox Trigger

The workflow starts with a Dropbox trigger that monitors a specific folder for new files. This trigger is the entry point that activates the entire automation whenever a resume is uploaded. To configure this trigger, you’ll need to connect your Dropbox account to Pipedream and specify which folder to monitor.

For this tutorial, we’re monitoring a folder called /Pipedream/Resumes. When you test the trigger with a sample resume, you’ll see that it returns metadata about the file including the filename, path, size, and modification dates. However, it’s important to note that the trigger only provides this metadata and not the actual file content. This is why we need a separate step to download the file, which we’ll configure in the next section.

The trigger activates immediately when a new file is detected, making the workflow responsive to your hiring needs. You can upload resumes throughout the day, and each one will be processed automatically without any manual intervention. This real-time processing ensures that candidate summaries are available to your team as quickly as possible.

Downloading the Resume File

After the trigger detects a new file, we need to actually download the file content before we can extract text from it. The Download File to TMP action retrieves the resume from Dropbox and saves it to Pipedream’s temporary storage, where subsequent steps can access it.

The configuration is straightforward. The Path parameter uses {{steps.trigger.event.path_display}} to reference the file path captured by the trigger. This action downloads the file and returns an object containing the temporary file path in the tmpPath property. The file remains in temporary storage throughout the workflow execution, which is perfect for processing and then discarding after the workflow completes.

The downloaded file is now ready for text extraction. The temporary file path will be used in the next step to read the PDF content and convert it into text that Claude can analyze.

Extracting Text from the PDF

With the resume downloaded to temporary storage, we now need to extract the text content from the PDF file. This step uses a Node.js code block with the pdf-parse library to read the PDF and convert it into plain text that Claude can analyze.

The code reads the file from the temporary path using Node.js’s built-in fs module, then passes the file buffer to pdf-parse for processing. The library handles the complexities of PDF parsing and returns the extracted text as a string.

import { PDFParse } from "pdf-parse";
import * as fs from "fs";

export default defineComponent({
  async run({ steps, $ }) {
    // Get the tmp file path
    const filePath = steps.download_file_to_tmp.$return_value.tmpPath;

    // Read the file from /tmp
    const dataBuffer = fs.readFileSync(filePath);

    // Parse the PDF
    const parser = new PDFParse({ data: dataBuffer });
    const resumeText = await parser.getText();

    // Return the PDF content
    return resumeText;
  },
})

The extracted text is now available in resumeText and ready to be analyzed by Claude in the next step.

Analyzing the Resume with Claude

This is where the intelligence happens. The Claude API step sends the extracted resume text to Anthropic’s Claude AI with detailed instructions to analyze the content and return structured data in JSON format. Claude examines the resume and extracts key information including work experience, skills, education, and provides insights that would typically require manual review.

The configuration of the Chat with Anthropic (Claude) action requires your Anthropic API key, which you can obtain from your Anthropic account. The request uses the claude-sonnet-4-5-20250929 model, which provides an excellent balance of speed, cost, and analytical capability for this task. The Maximum Tokens to Sample parameter is set to 4096, which gives Claude enough space to return a comprehensive analysis with all the fields we need.

The prompt is carefully structured to guide Claude in extracting specific information and formatting it as valid JSON. Here’s the complete prompt that instructs Claude on what to analyze and how to structure the response:

You are an expert HR analyst. Analyze the following resume and extract key information into a structured JSON format.

Resume content:
{{steps.code.$return_value.text}}

Please analyze this resume and provide a comprehensive summary in the following JSON structure. Be thorough but concise:

{
  "date": "YYYY-MM-DD (today's date)",
  "candidateName": "Full name from resume",
  "email": "Email address",
  "phone": "Phone number",
  "location": "City, State/Country",
  "summary": "2-3 sentence professional summary highlighting key qualifications, experience, and strengths",
  "yearsOfExperience": "X years (calculate total)",
  "currentPosition": "Most recent job title",
  "currentCompany": "Most recent company name",
  "skills": [
    "List 6-10 key technical and professional skills with proficiency levels where relevant"
  ],
  "highestDegree": "Degree name (e.g., Bachelor of Science in Computer Science)",
  "institution": "University/College name",
  "fieldOfStudy": "Major/Field",
  "strengths": [
    "List 4-6 key strengths based on achievements, projects, and experience"
  ],
  "recommendations": [
    "List 4-5 specific interview questions or topics to explore based on their unique experience"
  ],
  "fitScore": "Rate 1-10 based on overall qualifications and experience",
  "finalNotes": "2-3 sentence overall assessment and hiring recommendation"
}

IMPORTANT INSTRUCTIONS:
- Extract all information directly from the resume
- If any field is not available in the resume, use "Not specified" or an empty array []
- For skills, include proficiency levels when they can be inferred from years of experience or explicit mentions
- Make the summary compelling but accurate
- Base the fitScore on years of experience, skill diversity, education, and career progression
- Ensure all JSON is properly formatted with no syntax errors
- Return ONLY the JSON object, no additional text or markdown formatting

CRITICAL OUTPUT REQUIREMENTS:
- Return ONLY the raw JSON object
- Do NOT wrap the JSON in markdown code blocks
- Do NOT include ```
{% endraw %}
json or
{% raw %}
 ``` markers
- Do NOT add any explanatory text before or after the JSON
- The response must start with { and end with }
- The entire response must be valid, parseable JSON

Claude processes the resume text and returns a JSON object containing all the extracted information. The response includes everything from basic contact details to insightful recommendations for interview questions based on the candidate’s unique experience. This structured format makes it easy to pass the data to DocuGenerate for document generation in the next step.

Parsing the JSON Response

Claude returns its analysis as a JSON string, but we need to convert this into a structured object that we can work with in subsequent steps. Pipedream’s built-in Parse JSON action found under Formatting → Data handles this conversion automatically.

The configuration simply takes the Claude response from {{steps.chat.$return_value.content[0].text}} and parses it into a structured object. This parsed data becomes available to all subsequent steps in the workflow, allowing us to reference specific fields like {{steps.parse_json.$return_value.candidateName}} when we need them.

Having the data parsed into individual fields is particularly useful for dynamic file naming and for passing the complete dataset to DocuGenerate. The parsed object contains all the fields defined in our template: candidate information, summary, skills array, strengths array, recommendations array, and the overall assessment.

Generating the Summary Document

With the analyzed data now available as a structured object, we’re ready to generate the professional PDF summary. This step uses the DocuGenerate App on Pipedream to merge the data with our template and create a formatted document.

You’ll need your DocuGenerate API Key to set up a connection, which you can find in your account settings. The action configuration includes several important parameters:

Template specifies the Resume Analysis Summary template from the setup section
Name uses Resume Analysis for {{steps.parse_json.$return_value.candidateName}} to create a dynamic filename based on the candidate’s name
Format is set to PDF (.pdf) to generate a PDF document
Data contains the complete parsed JSON object {{steps.parse_json.$return_value}} from Claude with all the candidate information

The API processes this request and returns a response containing a document_uri field, which is a URL pointing to the generated PDF document.

Uploading the Analysis to Dropbox

The final step completes the workflow by uploading the generated PDF analysis back to Dropbox where your hiring team can access it. The Upload a File action saves the document to a designated folder, organizing all candidate analyses in one location.

The configuration requires specifying the destination path and the file content to upload:

Path specifies the /Pipedream/Analysis destination folder
File Name is set to {{steps.generate_document.$return_value.filename}} as the generated document’s file name
File Path or URL references the {{steps.generate_document.$return_value.document_uri}} value from the previous step
Mode is set to overwrite to define what to do if the file already exists

Once uploaded, the analysis is immediately available to your team, and you can optionally add an email notification step to alert hiring managers when a new candidate summary is ready for review.

Testing the Complete Workflow

With all steps configured, the workflow is ready to process resumes automatically. To test it, simply upload a resume PDF to the /Pipedream/Resumes folder in your Dropbox. The workflow will detect the new file within seconds and begin processing it through each step.

You can monitor the execution in real-time through Pipedream’s interface, which shows the data flowing through each step. Once finished, you’ll find the generated analysis PDF in your /Pipedream/Analysis folder in Dropbox, ready for your hiring team to review.

Extending the Workflow

The resume analyzer we’ve built provides a solid foundation, but there are many ways you can extend it to better fit your hiring process. Here are some practical enhancements you might consider adding to make the workflow even more valuable for your organization.

You could add an email notification step that alerts hiring managers immediately when a new candidate analysis is ready. This notification could include key highlights from Claude’s analysis, such as the fit score and professional summary, along with a direct link to the full PDF report in Dropbox. This eliminates the need for hiring managers to constantly check the folder for new analyses.

Another useful extension is storing the structured JSON data in a database or spreadsheet. By adding a step that sends the parsed data to Airtable, Google Sheets, or your applicant tracking system, you can build a searchable database of all candidates. This makes it easy to filter candidates by skills, experience level, or fit score when you’re looking for specific qualifications.

You might also want to customize the analysis based on the position you’re hiring for. You could create different templates for different roles and use the filename or a designated folder structure to determine which template to use. For example, resumes in /Resumes/Engineering could use a template that emphasizes technical skills, while those in /Resumes/Sales could focus more on communication abilities and deal experience.

Conclusion

Building an automated resume analyzer with Pipedream, Claude, and DocuGenerate demonstrates how AI and workflow automation can transform time-consuming manual processes into efficient, consistent operations. The workflow we’ve created processes resumes in seconds, extracts meaningful insights that would take humans much longer to identify, and generates reports that make hiring decisions easier.

This approach is particularly valuable because it maintains consistency in candidate evaluation. Every resume is analyzed using the same criteria, reducing unconscious bias and ensuring that all candidates are assessed fairly. The structured format of the analysis reports also makes it easier to compare candidates side-by-side and identify the most promising applicants for your open positions.

The workflow pattern we’ve demonstrated here extends beyond resume analysis. The same approach of extracting text from documents, using AI to analyze and structure the content, and generating formatted reports can be applied to many other document processing scenarios. Whether you’re analyzing contracts, processing customer feedback, or extracting data from research papers, the core workflow remains similar with adjustments to the analysis prompt and output template.

Resources

The Resume Analysis Summary template for DocuGenerate.
The official DocuGenerate App for Pipedream.
The Anthropic (Claude) App on Pipedream.
The Dropbox App on Pipedream.

Automate PDF Invoice Generation with n8n and DocuGenerate

DocuGenerate — Fri, 24 Oct 2025 00:00:00 +0000

Introduction

Document automation doesn’t always require cloud-based solutions, sometimes the most effective workflows are the ones that run locally on your machine. In this tutorial, we’ll explore how to build an automated invoice generation system using n8n, a powerful workflow automation tool, combined with DocuGenerate to create professional PDF invoices.

The workflow we’ll build is straightforward yet powerful. It monitors a designated folder on your local machine for new Excel files containing invoice data. When a file appears, the workflow automatically reads the data, generates a separate invoice for each row, and saves the completed PDF documents to an output folder. This approach is particularly useful for businesses that need to process invoices locally and maintain full control over their data.

Throughout this guide, we’ll walk through each node in the n8n workflow, explaining its purpose and configuration. By the end of this tutorial, you’ll have a fully functional local invoice generation system that you can adapt to your specific needs.

Setting Up the Template

Before building the n8n workflow, we need to prepare our invoice template. DocuGenerate’s Template Library includes a ready-to-use Repair Invoice template that’s perfect for this tutorial. You can learn more about using templates from the library in our previous guide.

The template contains merge tags like Invoice No, Customer Name, Product Name, and other common invoice fields. These merge tags will be automatically replaced with actual data from the Excel file during the document generation process. The template also includes a sample Excel file with ten rows of invoice data, which we’ll use to demonstrate the workflow.

Once you’ve downloaded the template from the library, upload the file Repair Invoice.docx to your DocuGenerate account. With the template ready, we can now turn our attention to building the n8n workflow that will automate the entire invoice generation process.

The Complete Workflow Overview

The workflow we’re building consists of several interconnected nodes that work together to monitor for files, process data, generate documents, and save the results on the disk. Here’s what the complete workflow looks like in n8n:

The workflow begins with a trigger that watches a local folder for new files. When an Excel file is added, the workflow validates the file extension, reads the file content, extracts the data into structured rows, and then loops through each row to generate an individual invoice. Each generated invoice is downloaded and saved to a designated output folder on your local machine. This entire process runs automatically, requiring no manual intervention once configured.

If you’d like to import this workflow directly into your n8n instance, you can download the workflow JSON file and import it. This can save you time and ensure all the nodes are configured correctly. Now let’s examine each node in detail to understand how the workflow operates.

Configuring the Local File Trigger

The workflow starts with the Local File Trigger node, which monitors a specific folder on your computer for new files. This trigger is the entry point for the entire automation process. For this tutorial, we’re watching the /Users/docugenerate/n8n/Data folder, but you can configure this to any directory on your system where you plan to add Excel files.

The trigger is configured to detect the File Added event, meaning it activates whenever a new file appears in the monitored folder. This is ideal for batch processing scenarios where you might drop multiple Excel files into a folder throughout the day and want them processed automatically. The trigger captures the file path and passes it to the next node in the workflow.

For this example, we’ll be using the Repair Invoice.xlsx file from the sample template, which contains ten rows of invoice data. Each row represents a separate invoice with details like invoice number, customer information, service descriptions, and amounts.

Validating the File Extension

After the trigger detects a new file, we need to verify that it’s actually an Excel file before attempting to process it. The If node serves this purpose by checking whether the file path ends with the .xlsx extension. This validation step prevents errors that could occur if someone accidentally drops a different file type into the monitored folder.

If the condition evaluates to true, the workflow continues to the next step. If false, the workflow stops, preventing unnecessary processing of incompatible files. This simple check adds robustness to the workflow and ensures that only valid Excel files are processed.

Reading the File from Disk

Once we’ve confirmed that the file is an Excel spreadsheet, the Read File from Disk node retrieves the actual file content from your local machine. This node uses the file path provided by the trigger to locate and read the binary data of the Excel file.

The configuration is straightforward. The File(s) Selector parameter is set to {{ $json.path }}, which references the path captured by the trigger. In the options section, we specify data as the name of the output binary field where the file content will be stored. This field name will be used in subsequent nodes to access the file data.

It’s important to note that this node works with files on the same computer running n8n. If you need to handle files between different computers, you would need to use alternative nodes such as FTP, HTTP Request, or AWS S3 nodes. For local processing scenarios like ours, this node provides a simple and efficient solution.

Extracting Data from the Excel File

With the file content now available as binary data, we need to convert it into a structured format that can be processed by the workflow. The Extract from File node handles this transformation by parsing the Excel file and converting each row into a separate data item.

The node is configured with the Extract from XLSX operation, and the Input Binary Field is set to data, which matches the field name we specified in the previous node. This step is essential because it transforms the raw binary file data into structured JSON objects that contain the invoice information from each row. These structured data items can now be processed individually to generate invoices.

Looping Through Each Invoice Record

Now that we have the structured data items from the Excel file, we need to process each one individually to generate a separate invoice. The Loop Over Items node enables this by iterating through the items in batches. For this workflow, we’re using a batch size of one, meaning each invoice is generated and saved before moving to the next one.

This batching approach is particularly useful for document generation because it ensures that each invoice is completely processed before starting the next one. It also helps manage system resources when dealing with larger datasets. The loop continues until all items have been processed, with the workflow executing the same sequence of nodes for each invoice record.

Generating the Invoice Document

The Generate Document node that takes the data from each row and merges it with the template to create a PDF invoice. To use this node, you’ll need to install the DocuGenerate node in your n8n instance.

The node configuration requires several parameters:

Template Name or ID is set to Repair Invoice, which matches the template we uploaded earlier.
Name uses an expression Invoice no {{ $json['Invoice No'] }} to dynamically name each document based on the invoice number from the data.
Format is set to PDF (.pdf) to generate PDF documents.
Data is configured with {{ $json }}, which passes the entire current data item to the document generation API. This means all the fields from the Excel row are available for merge tags in the template.

The API processes this request and returns a response that includes a document_uri field pointing to the generated document.

Downloading the Generated Document

After DocuGenerate creates the invoice, Get File from URL uses the built-in HTTP Request node to retrieve the generated PDF from the URL provided in the previous step’s response.

The URL parameter is set to {{ $json.document_uri }}, which references the document URL returned by the Generate Document node. In the options section, the Response Format is configured as File to ensure the data is treated as binary content rather than text. The Put Output in Field option is set to data, storing the PDF content in a field that can be accessed by the next node.

For this example, the generated document has the filename Invoice no 58-223-0655.pdf, which was dynamically created based on the invoice number in the first row of our sample data. Each subsequent invoice will have its own unique filename following the same pattern.

Saving the Invoice to Disk

The final step in the workflow saves the generated invoice PDF to a designated folder on your local machine. The Write File to Disk node handles this operation, storing each completed invoice where you can easily access it.

The File Path and Name parameter is configured with /Users/docugenerate/n8n/Invoices/{{ $data.filename }}, which combines a base directory path with the dynamic filename from the generated document. The Input Binary Field is set to data, which contains the PDF content retrieved in the previous step.

This configuration saves all invoices to the same folder, but you could customize this further. For example, you might organize invoices by date, or group them by customer name. The flexibility of n8n expressions allows you to create any folder structure that suits your business needs. Just keep in mind that this node is designed for working with files on the same computer running n8n.

Running the Workflow

With all the nodes configured, the workflow is ready to process invoices automatically. To test it, simply add the Repair Invoice.xlsx file to the Data folder that the trigger is monitoring. The workflow will immediately detect the new file and begin processing.

The animation above shows the Loop Over Items segment in action, iterating through all ten data items from the Excel file. For each item, the workflow generates an invoice using the template and data, downloads the PDF, and saves it to the destination folder. You can watch the progress in real-time through n8n’s visual interface, which provides excellent visibility into each step of the process.

Once the workflow completes, all ten invoices have been generated and saved in the Invoices folder. This automated approach eliminates the need for manual document creation, saving significant time and reducing the potential for errors that can occur with manual data entry.

Conclusion

Building local automation workflows with n8n and DocuGenerate offers a powerful solution for businesses that need to process documents efficiently while maintaining full control over their data. The workflow we’ve built demonstrates how easy it is to monitor folders, validate files, extract data, and generate professional documents without relying on cloud services or complex integrations.

This approach is particularly valuable for scenarios where data privacy is paramount, internet connectivity is limited, or you simply prefer to keep your document processing pipeline local. The flexibility of n8n allows you to extend this workflow in numerous ways. You could add email notifications when invoices are generated, create backup copies, or integrate with your existing business systems with other solutions.

The workflow we’ve created processes repair invoices, but the same pattern can be applied to any document type supported by DocuGenerate. Whether you need to generate contracts, letters, certificates, or reports, the core workflow remains the same. You simply need to adjust the template and ensure your Excel data matches the merge tags in your chosen template.

Resources

The n8n workflow JSON file that you can import into your n8n instance.
The Repair Invoice template from DocuGenerate’s Template Library.
The official n8n documentation page.
The complete DocuGenerate integration guide for n8n.