Gravity Flow PDF Generator - WordPress Plugin

A Guide to Configuring Gravity Flow PDF Generator for PDF Documents in WordPress Workflows

Gravity Flow PDF Generator is not just a standalone "make a PDF" button. It works best as a step inside an existing Gravity Flow workflow. In this guide, we'll look at where that step makes sense, how to prepare the form, how to build a template with merge tags, when to email the file, when to provide a download link, and how to verify that the document is generated at the right moment.

This guide is written for a WordPress administrator who already uses Gravity Forms and wants to turn a submitted request, agreement, service report, internal approval, or summary into a PDF without manually copying data. It does not cover purchasing or license activation. The focus here is practical use after installation: process structure, step settings, permissions, the file on the server, email attachments, font troubleshooting, and safe customizations.

The core idea is simple: the PDF should appear at the point where the business process has already reached the necessary decision. If the document is generated too early, it will contain unverified data. If it is generated too late, the team loses time and participants may miss the confirmation. That is why setup should start not with a polished template, but with a workflow map: which form collects the data, who reviews it, which step confirms that the document is ready, and who should receive the result.

What the PDF Step Does Inside Gravity Flow

Gravity Flow PDF Generator adds a dedicated step type to Gravity Flow that generates a PDF from Gravity Forms entry data. The official documentation describes it as a way to add a PDF creation step at any point in the process. That wording matters: the product does not replace Gravity Forms, it does not create a standalone document workflow outside WordPress, and it is not a universal editor for complex PDF layouts. It works within Gravity Flow logic, where an entry moves through a sequence of steps.

In practice, this is useful for workflows where the document is the result of a decision or entry state. For example, a service request is first completed by a customer, then reviewed by a staff member, then approved by a manager, and only after that does the system generate a PDF confirmation. In another scenario, the PDF can be created immediately after user input if the document is simply meant to be a copy of the submitted form. The difference between these approaches is not technical, but procedural: the PDF should capture the set of data that is already considered final.

The PDF template is configured much like Gravity Forms notifications: you insert merge tags into the text, and they output field values, system data, and workflow elements. That lowers the entry barrier for administrators who already know how Gravity Forms notifications work. Instead of dealing with an external template file, the administrator works directly in the step settings. For simple documents, that is enough: request confirmations, approval summaries, internal check sheets, result letters, or short request reports.

The complexity starts when the PDF needs to be a fully designed document with precise layout control, multiple templates, logos, custom fonts, PDF/A, password protection, or custom PHP templates. In those cases, it is important to assess the tool's boundaries honestly. Gravity Flow documentation explicitly points to Gravity PDF for more advanced PDF use cases. So Gravity Flow PDF Generator is best viewed as a workflow-native tool: it is strongest when the document needs to appear at the right point in the process, not when you need a dedicated PDF design system.

Common Use Cases

The most natural scenarios involve an entry that changes status and needs to leave a verifiable document trail. That can include leave requests, internal requests, agreements for approval, service reports, participation requests, registration confirmations, review results, or documents for further CRM processing. In each case, the PDF should answer three questions: which data came from the form, at what stage of the process it was locked in, and who is allowed to receive the file.

• Customer copy of a submitted form: the PDF is generated after required data has been checked and sent to the applicant.
• Internal document for the team: the PDF is created after an approval step and attached to a notification for responsible staff members.
• Process archive: the PDF preserves the final entry data and helps restore context quickly without opening every form field.
• Document after a conditional branch: the PDF is generated only for a certain request type when the Step Condition skips all other cases.
• Delayed delivery: Schedule lets you postpone generation if the document should appear after an event date or after earlier steps have finished.

If the process consists of a single simple form submission and an immediate email to the user, a standard Gravity Forms notification or a dedicated Gravity Forms PDF plugin may be enough. But if the sequence matters - "data - review - decision - document - delivery" - Gravity Flow PDF Generator is usually the more logical option because it lives inside the same chain of steps.

Who This Product Fits and When to Choose Another Approach

Gravity Flow PDF Generator is a good fit for sites that already use Gravity Flow or plan to. That could be a corporate WordPress site, a request portal, an educational project, a service team, an HR department, an agency handling multistep requests, or a small internal portal. The key sign of a good fit is that form data is not just emailed to an administrator, but moves through a workflow with participants, statuses, deadlines, notifications, and checks.

The product is especially useful when the document needs to be generated at a specific workflow step rather than immediately after form submission. For example, the applicant submits a form, a coordinator clarifies details through a User Input Step, a manager approves the entry through an Approval Step, and only then does the PDF become the official confirmation. In that scenario, generating a PDF right after submit would be premature: the document would miss corrected data and would not reflect the final decision.

There are also cases where another path makes more sense. If you need a visually rich PDF with many ready-made designs, advanced typography, paper settings, a template marketplace, Entry List access, and a separate PDF template system, it makes sense to compare this product with Gravity PDF. If you need to fill in existing PDF forms, such as official forms, banking paperwork, or insurance documents, Fillable PDFs by CosmicGiant may be a closer match. If the PDF only needs to be a simple attachment to a standard Gravity Forms notification after submission, and no workflow is involved, introducing Gravity Flow just for one file may be unnecessary.

Signs You Are Making the Right Choice

Before installing, it helps to run through a quick check. If the answer to most of these questions is "yes," the product is probably a good fit.

• The site already uses Gravity Forms, and the form entries are the source data for the document.
• The process is built, or will be built, in Gravity Flow, and the PDF is needed as one step in that process.
• The administrator is comfortable using an HTML template with merge tags, without a separate visual PDF builder.
• The file needs to be sent to selected workflow participants or made available via download link with access control.
• The team is willing to test the process on a separate form before enabling it in the live workflow.

When the Product May Not Be a Good Fit

You should not expect Gravity Flow PDF Generator to provide the features of a full DMS platform, an external document repository, or an e-signature service. It generates PDFs on the WordPress server and integrates into the workflow, but it does not automatically solve every legal or archival requirement. If the project depends on long-term retention, access auditing, strict personal data policies, archive encryption, or integration with an external document management system, those requirements need to be designed separately.

You should also be more cautious with multilingual documents that require Chinese, Japanese, Korean, or nonstandard fonts. The official font troubleshooting documentation explains that some font files are excluded from the extension package to avoid making the archive too large, and if characters are missing, you may need a separate fonts directory and hook-based configuration. That is manageable, but it should be part of the testing plan rather than something you discover after launch.

Practical rule: choose Gravity Flow PDF Generator when the PDF is the outcome of a workflow step. If the PDF itself is the main deliverable on the page and requires complex design, compare it with more specialized PDF tools for Gravity Forms.

What to Check Before Installation and Your First PDF Step

Preparation matters not because installation is difficult, but because several layers are involved: WordPress, Gravity Forms, Gravity Flow, email delivery, user permissions, fonts, and form logic. The official product page lists the required current versions of Gravity Flow and Gravity Forms, and PDF Generator Extension 3.0 adds an important PHP requirement: the version built on the updated mPDF requires PHP 8.0 or higher. There is no need to anchor the article to specific dates, but before installation, you should check the server so you do not run into a PHP-level compatibility issue.

Start with a test form. Do not configure your first PDF step on a live form that is already receiving customer submissions. Create a copy of the form or a separate technical form with the same field types: name, email, service list, description textarea, file upload, internal status, and a field for selecting the document type. That form will let you test merge tags, conditional steps, email attachments, and the download link without risking real entries.

Platform Check

At the server and WordPress level, check four things. First, the PHP version must meet the requirements of the installed extension version. Second, Gravity Forms and Gravity Flow should both be updated to compatible versions. Third, the site needs a reliable email channel: an SMTP plugin, a transactional mail service, or another dependable delivery method, because a PDF attachment will not save an email if WordPress is already failing to send mail. Fourth, the server should have enough resources for PDF generation, especially if the document includes many fields, long tables, or images.

Also check updates. For commercial Gravity Flow extensions, the proper path usually goes through the official account or built-in update mechanism. Do not pull installation archives from third-party libraries, because document workflows often involve personal data. Even if the extension installs successfully, the source of the archive becomes a weak point in the whole chain.

User Roles and Permissions

Gravity Flow uses the WordPress roles and capabilities system. The permissions documentation lists separate capabilities for settings, step creation, inbox, status, and viewing all workflows. For PDF Generator, that matters in two places. First, who is allowed to create and edit the workflow step. Second, who can open the entry and download the PDF if the link is not signed.

The PDF Generator documentation states that an unsigned link checks the current user's access: this may include the ability to view Gravity Forms entries, access to Gravity Flow status, or whether the user is the assignee of the current step. So for restricted documents, it is better not to hand out permanent open links unless there is a clear reason. If an external recipient needs access, use a signed link with a limited lifespan and understand that permission checks will be bypassed for that link.

Form Data and Template Quality

A good PDF starts with good fields. If the form does not contain structured data, the PDF turns into a long wall of text. Before configuring the PDF template, give fields clear names, split long textareas into logical blocks, make required fields mandatory where the document should never be blank, and configure conditional logic at the form level. Then your merge tags will output predictable values rather than random fragments.

For documents that will be sent to customers, prepare a short map: which fields go into the PDF, which stay in the admin area only, which fields are needed for conditions, and which should never appear in the external document. Do not use the generic {all_fields} without reviewing it if the entry contains internal comments, system fields, or data that should not be sent to the recipient.

Installation and Initial Verification in the WordPress Admin

Installing the extension is broadly similar to installing other premium WordPress plugins: the administrator uploads the ZIP archive, activates the plugin, and checks that the required step type appears in the workflow settings. This guide does not cover purchasing, license keys, or account management. For process quality, something else matters more: after activation, you need to confirm that the site recognizes Gravity Forms, Gravity Flow, and the new PDF step as one connected system.

Open the WordPress admin and go to the form where the process will be tested. In Gravity Flow, the workflow is typically configured through the selected form's Form Settings. If PDF Generator is active and its dependencies are available, the list of step types should include a PDF Generator step. If it does not, first check plugin activation and version compatibility rather than looking for a separate PDF settings page in the WordPress menu. This product works specifically through a workflow step.

Minimum Post-Activation Test

You do not need a complex template for the first test. Create a workflow with one PDF step after form submission or after a simple approval step. In the template, add the document title, a couple of form fields, and a system line with the entry ID. Then submit a test entry. If the step runs correctly, you can verify file creation through the download merge tag or through an email attachment, depending on the setting you chose.

1. Open the test form and make sure all fields that will appear in the PDF are filled with meaningful data.
2. In the workflow settings, add a new step and choose the PDF Generator type.
3. Give the step a clear name, such as Generate approval summary PDF, so it is easy to find in the list.
4. Add a short template with merge tags and save the step.
5. Create a test entry and move the workflow to the PDF step.
6. Check the entry timeline, the email, the download link, and the presence of the expected file.

If the PDF is not generated on the first test, do not expand the template. Do the opposite and temporarily reduce it to two or three lines. That helps separate a generation problem from a problem caused by specific markup, a font, a field, or email delivery. Once the basic check succeeds, you can gradually bring back formatting, conditions, and additional merge tags.

What Counts as a Successful Initial Check

A successful check is not just the presence of a file. You need to confirm four outcomes. The workflow reaches the PDF step without getting stuck. The PDF contains exactly the values stored in the entry. The recipient receives the email or link in the expected place. A second test with a different entry does not overwrite the older document in an unpredictable way. If any one of these points fails, the process is not ready for a production site.

Do not overcomplicate the first test. The earlier you add a long template, nested conditions, and nonstandard fonts, the harder it becomes to tell whether PDF generation itself failed or just one specific part of the document.

Configuring the PDF Template: Merge Tags, Structure, and Readability

Template setup is the core of working with Gravity Flow PDF Generator. The documentation emphasizes that PDF templates are built using merge tags similar to notifications. That is convenient, but it can become messy quickly if you just dump every field into the document. A good template should be shorter than the form itself, because the document records the result rather than reproducing the entire entry interface.

Start with the document structure. At the top, include the document title and key identifier: entry number, applicant name, request type, or another business-oriented reference. Then organize the main data into blocks: participant, request subject, decision, comment, event date, amount, or selected service, if relevant. At the end, you can add an internal section: current step, status, entry link, or a short note for the internal team. Do not mix customer-facing and internal data in one document if the PDF will be sent to an external recipient.

How to Use Merge Tags Without Creating Chaos

Gravity Forms and Gravity Flow provide many merge tags. That does not mean every one belongs in the PDF. For a readable document, select only the fields that serve the purpose of that document. If it is a request confirmation, you need contact details, the selected service, the final decision, and next steps. If it is an internal report, you may want assignees, workflow timeline, or system fields. If it is a customer document, internal notes and admin-only fields should usually be excluded.

It is convenient to use simple HTML markup in the template: headings, paragraphs, short tables, and lists. Complex CSS techniques, scripts, and interactive elements are unnecessary. A PDF should be predictable and printable. For long repeating data, create a separate section instead of forcing everything into a single table. If you use {all_fields}, verify that hidden, administrative, or technical fields are not being pulled into the document.

Example of a Simple Template Skeleton

The snippet below is not a universal template for every site. It is a safe starting point. Replace the field names and merge tag numbers with the actual values from your form using the merge tags menu in the Gravity Forms editor.

<h2>Summary for request #{entry_id}</h2>
<p><strong>Requester:</strong> {Name:1}</p>
<p><strong>Email:</strong> {Email:2}</p>
<p><strong>Request type:</strong> {Request Type:3}</p>
<h3>Approved details</h3>
<p>{Approved Details:7}</p>
<h3>Workflow note</h3>
<p>{workflow_note}</p>

After inserting a structure like this, test the PDF with three sample entries: a short one, a long one, and one with an empty optional field. That will show whether the document breaks with long text and whether empty headings are left behind where no data exists.

Download Links and Expiration

If you do not enable PDF delivery by email, the documentation suggests using the merge tags {workflow_pdf_download_link} or {workflow_pdf_download_url}. The first outputs a clickable link, while the second gives you the raw URL. The {workflow_pdf_download_link} tag supports the parameters text, signed, and expires. One important detail: the text parameter is not supported by {workflow_pdf_download_url}, and a signed link bypasses permission checks.

For internal users, an unsigned link is often enough: the system will check whether the current user has access to the workflow entry. For an external recipient who does not log in to WordPress, you may need a signed link with a limited lifespan. In that case, the expiration period should be short and intentional. Do not turn that kind of link into a permanent public URL for sensitive documents.

{workflow_pdf_download_link: text="Download your document" signed="true" expires="1 day"}

In a localized email, you can make the link text more user-friendly, but the merge tag syntax itself remains in English. Check it in the editor and do not translate the text, signed, and expires parameters, because they are part of the technical syntax.

Page Breaks and Long Documents

The PDF Generator documentation notes that you can use the <pagebreak /> tag for a page break. This is useful when the document contains a cover section, the main information, and an internal appendix. Do not insert page breaks after every block or the PDF becomes inconvenient to read. It is better to use them before logically separate sections, such as before a long list of terms or before an internal review sheet.

If the document includes large tables, first ask whether the PDF really needs to contain every row. Sometimes it is better to generate a short summary and leave a link to the entry in the admin area for the full detail. The more dynamic content you include, the greater the risk of layout, font, and file-size issues.

Delivering the PDF: Email Attachment, Server Download, and Access Control

Once the template is ready, the next step is deciding how the user will receive the file. Gravity Flow PDF Generator supports two practical options: the PDF can be sent as an email attachment, or it can remain available for download through merge tags. These options are not interchangeable. An email attachment works well for a document that needs to be delivered immediately. A link is better when access should depend on the user's permissions, link expiration, or workflow context.

The documentation states that when Send by email is enabled, the PDF is sent to the selected users, and choosing a role sends the email to all users in that role. Gravity Forms merge tags are also supported, so the recipients and email content can be dynamic. If Custom File Name is used, the filename can be set separately, and slashes are removed from the name to avoid folder-related issues. That is a small but important detail: do not try to create a nested structure through the filename.

Email Attachment: When It Makes Sense

Email attachments work well for confirmations and internal notifications. For example, after a request is approved, the PDF is sent to the applicant and the coordinator. The recipient gets the document right away, and the workflow keeps moving. But attachments have limits: mail servers may block large messages, the recipient can forward the file, and the fact that it was sent does not mean it was read. So for confidential documents, email alone should not be your only line of defense.

If you send the PDF to multiple roles, verify the actual user list. In WordPress, roles often include people who no longer participate in the process. Before launch, it is better to create a separate role or use more precise targeting through an email field or assignee. This matters especially for HR, finance, and client-facing documents.

Server Download: When It Is Safer

A download link is useful when the document should be opened from the workflow interface or from an email with access control. An unsigned link checks the current user's permissions. A signed link with signed="true" is intended for external recipients, but it bypasses permission checks, so the expires period should be limited. For sensitive documents, shorter expiration is usually better, and signed links should not be placed on public pages.

Think through what happens after the email is sent. The documentation for the gravityflowpdf_delete_post_send hook explains that by default, a PDF sent by email is deleted immediately afterward to reduce the risk of later access to field values elsewhere in the workflow. That is a sensible privacy default. If you need a server-side archive, change this only deliberately and only after reviewing folder access, backups, and retention policy.

Filenames Without Surprises

For the user, the filename often matters more than it seems. A file named document.pdf gets lost, while request-458-summary.pdf is much easier to find. The documentation for gravityflowpdf_download_file_name shows a filter for changing the filename of a downloadable PDF delivered through a merge tag. At the same time, the older gravityflowpdf_file_name hook is marked as deprecated in some scenarios, because changing the server-side filename could interfere with merge tags and download links. So for modern customizations, the safer starting point is the current filter for the download filename.

If the step settings are enough to define the filename, do not write code. A hook makes sense when the name depends on the step, the form, the entry ID, or some business value. Even then, avoid personal data in the filename: email addresses, phone numbers, passport details, or internal customer IDs. Filenames often end up in mail logs, download history, and backups.

Configuring Conditions, Scheduling, and PDF Placement in the Workflow

The biggest difference between Gravity Flow PDF Generator and simpler PDF plugins for form submission is that it inherits Gravity Flow step logic. The documentation for common step settings describes Name, Description, Step Type, Highlight, Condition, Schedule, and Next Step. For PDF Generator, that means the document does not have to be created every time, immediately, or for every entry. This is where the product becomes useful for real processes.

Start by answering one question: what needs to happen before the PDF is generated? If the document confirms an approved request, it should come after an approval step. If the document needs to include clarified data, it should come after a user input step. If the PDF is needed only for a certain selection in the form, configure a Condition. If the PDF should be sent after an event date or no earlier than the next business stage, use Schedule. If something needs to happen after the PDF - send a notification, check status, or route the entry into another branch - think through the Next Step.

Condition: Do Not Generate Unnecessary Documents

Condition allows the step to be skipped when the entry does not match the rules. For PDF Generator, this is especially useful because not every request type should turn into a document. For example, a form collects three kinds of submissions: consultation, contract, and internal request. The PDF may only be required for the contract. In that case, a condition based on the Request Type field saves resources, reduces file clutter, and removes confusion in email notifications.

Test the condition on several entries. One entry should trigger the PDF, another should skip the step, and a third should test an edge case, such as an empty optional field or a changed request type. If the condition depends on choice values, do not change form labels without retesting the workflow. In more complex processes, it is helpful to add an internal Description to the step explaining why the PDF is generated only under these conditions.

Schedule: When the Document Is Needed Later

Schedule delays the step based on time, date, or the value of a date field. For PDFs, this is useful when the document should be generated after an event rather than immediately after approval. For example, a participation confirmation could be sent the day before an event, while a service report might be generated after the maintenance window ends. But do not use scheduling just to work around email issues. Email delivery problems should be fixed in the mail infrastructure, not masked with arbitrary PDF step delays.

Next Step and Step Order

The step order documentation reminds you that steps run in sequence, and Next Step can control transitions. For PDF Generator, the important point is not to place it between two steps that still change the document data. If a User Input Step appears after the PDF step and a staff member edits the address or amount there, the generated PDF may already be outdated. In most cases, the document belongs after the last step that affects its content and before the notification that delivers the result.

Practical Example: PDF Confirmation After Request Approval

Let's look at a concrete scenario. The site has a form called "Service Request." The customer enters their name, email, service type, task description, and preferred date. A coordinator reviews the request, clarifies details through user input if needed, a manager approves execution, and after the approval step the customer receives a PDF confirmation with the final data. This is a typical case where the PDF is not needed at submit time, but after an internal decision.

Goal

The goal is to generate a PDF that confirms the approved request and contains only the agreed data: customer name, email, service type, final description, date, team comment, and entry number. The PDF should be emailed to the customer as an attachment and remain available for internal review through the workflow entry. If the request is rejected, no PDF should be created.

Preparation

Before configuration, create a test form with the required fields. Add a system field for the final comment if that comment is entered by staff after submission. Configure Gravity Flow so the first step is user input or coordinator review, the second is the manager's approval step, the third is a PDF Generator step with a condition that the request has been approved, and the fourth is a notification or workflow completion. If the approval step already sends a notification, decide whether the PDF step will send the attachment itself or whether the email should be handled in a separate step.

Setup Steps

1. Open the workflow settings for the selected form and add a PDF Generator step after the approval step.
2. Name the step so it reflects the outcome, for example Generate approved request PDF.
3. In Description, document the internal logic: the PDF is generated only after request approval and is sent to the customer.
4. Add the document heading, the main customer fields, the final comment, and the entry ID to the template.
5. In Condition, specify that the step should run only when the request is approved or when the field that records approval has the required value.
6. Enable email delivery if the document should be sent to the customer, and choose the email field as the recipient.
7. If you need a custom file name, set a clear one without slashes and without sensitive data.
8. Save the step and create several test entries: an approved one, a rejected one, and one with a long description.

Checking the Result

After submitting the test entry, move through the workflow as if you were a real participant. Make sure the PDF is not created before approval. After approval, check the customer email: the attachment should open, contain current data, and exclude internal fields the customer does not need. Then open the entry in the admin area and review the timeline. If there is a PDF error note, do not ignore it. That is the main diagnostic trail.

The rejected entry should follow a different path and should not generate a PDF. If a PDF appears for a rejected request, the condition is too broad or is attached to the wrong step. The entry with the long description will show whether the layout breaks, whether the table shrinks into something unreadable, and whether a page break is needed.

A Detail People Often Miss

If the coordinator changes data after the original submit, make sure the template uses the final fields rather than old values or an internal draft. In Gravity Flow, all entry edits need to be complete before the PDF step runs. If the PDF is generated earlier, it will not automatically rebuild itself just because another participant later corrected the text. Regeneration needs to be part of the process by design: a restart step, a new PDF step, or separate workflow logic.

Participant Roles, Privacy, and Ongoing PDF Process Support

A PDF document in Gravity Flow almost always sits at the intersection of several roles. There is the person who submits the form. There is the assignee who reviews or completes the entry. There is the administrator who designs the workflow. There is the PDF recipient, who may be the same person or may be accounting, sales, an academic coordinator, or an external client. If those roles are not defined before configuration, PDF Generator may work technically, but the process remains fragile: the wrong person sees the document, the email goes to an entire group, or the download link is forwarded without anyone understanding how long it remains valid.

Start with a simple access matrix. In the rows, list the process stages: form submission, review, approval, PDF generation, email delivery, download, and storage. In the columns, list the roles: applicant, coordinator, manager, administrator, external recipient. For each cell, answer whether that person should be able to view the entry, edit fields, receive the PDF, download the PDF later, and see internal notes. A matrix like this helps keep two separate questions distinct: who manages the workflow, and who receives the final document.

Internal and External PDFs Should Not Always Be the Same File

A common mistake is trying to create one universal PDF for every participant. The internal team needs system comments, workflow notes, technical entry numbers, the responsible staff member, and sometimes approval history. The customer needs a clear document without the internal backstory: what was approved, which data was confirmed, and what happens next. If you combine those requirements, either the customer sees too much or the team loses important context.

It is better to separate documents by purpose. One PDF Generator step can create the external document after approval, and another can create an internal summary for the team. Each step will have its own conditions, template, recipients, and filename. That adds more settings, but it reduces the risk of leaking internal data. This is especially important for HR, medical, education, finance, and B2B requests, where even without legal terminology it is obvious that an internal note and a customer confirmation are not the same document.

How to Document the Configuration for the Next Administrator

Gravity Flow lets you define a Description for each step. Use that field as more than a formality. Treat it as a short technical note. Record why the PDF sits after this specific approval step, which fields are considered final, who receives the file, and which hooks affect the result. A few months later, that can save hours of troubleshooting. The next administrator will see not just Generate PDF, but an actual reason: "creates the customer confirmation after coordinator approval, excludes internal notes, signed link has a short expiration."

It is also worth maintaining a separate page in the team knowledge base or site documentation. Store the workflow diagram, the list of PDF steps, the purpose of each template, test entries, the contact person responsible for email delivery, and the list of snippets. If gravityflowpdf_mpdf is used for fonts or gravityflowpdf_download_file_name is used for filenames, note where the code lives and how to disable it. The documentation does not need to be long. Its job is to give the next administrator a clear starting point.

Retention Policy and Backups

PDFs that contain form data often end up in backups. If you change the default behavior and keep the file after email delivery, check not just the folder but also the backup policy. The document may remain stored longer than the WordPress entry itself. That becomes especially problematic if a user asks for their data to be deleted while the file still exists in an archive. So before enabling long-term storage, answer three questions: where the PDF is stored, who has access to the folder, and when the file is deleted.

In smaller workflows, it is often more sensible not to keep extra copies. If the document is needed by the recipient, send it or provide a temporary link. If the document is needed by the team, make sure access to the entry and timeline is convenient enough. Storing PDFs on the server makes sense when there is a clear internal policy in place, for example, archive approved documents by entry number and delete them after a defined period. Without that kind of policy, saved files quickly become an unmanaged archive.

Change Control After Launch

Once the PDF process is live, you cannot change the form casually. Renaming a field, changing a choice value, deleting a hidden field, or moving a step can affect the document without obvious warning. Put a rule in place: every change to the form, workflow, notification, or snippet must go through a short PDF regression test. Two or three test entries are enough: a normal entry, one with long text, and one that should be skipped by the condition.

If the team changes the form frequently, add an internal document version marker to the PDF template as plain text or a system line without a date. This is not the plugin version and not a date in the article, but a local process marker such as Template: request-summary-v2. It helps you identify which template generated an older document once different PDF variants start appearing in the archive. Do not show that marker to the customer unless it is useful to them.

Key maintenance practice: treat the PDF step as part of the business process, not as a decorative attachment. It should have an owner, a test process, clear recipients, and a documented change procedure.

Checking PDF Quality and Making Safe Improvements Without Editing Core Files

Once the PDF is being generated, the job is not finished. You still need to verify document quality: data output, appearance, access, delivery, repeatability, and behavior under failure conditions. On a production site, it is useful to maintain a checklist that the administrator goes through after every form, workflow, or template change. The PDF step depends on the field structure, so even a small form edit can affect the document.

Result Checklist

• The document is generated only at the correct workflow step and does not appear for entries that should be skipped by the condition.
• All merge tags output data instead of appearing in the PDF as raw text.
• The PDF does not contain hidden system fields, internal notes, or data that is not intended for the recipient.
• The email attachment reaches the expected recipient, and the email subject and message clearly explain what the document is.
• The download link works for the intended user and does not work for a user without access if it is unsigned.
• If a signed link is used, it has a limited lifespan and is not published on open pages.
• The filename is clear but does not expose unnecessary personal data.
• The document opens correctly in a standard PDF viewer and prints normally.

Safe Customization of the Download Filename

Not everyone needs code. But if the site has several PDF steps and users download documents through {workflow_pdf_download_link}, it can be useful to add a short prefix to the downloaded filename. The documentation confirms the gravityflowpdf_download_file_name filter specifically for a downloadable PDF file delivered via merge tag. Code like this should live in a small site-specific plugin or a trusted code snippets plugin, not in the plugin core or in theme files that may be lost during a redesign.

add_filter( 'gravityflowpdf_download_file_name', 'site_prefix_gravityflow_pdf_download_name', 10, 3 );

function site_prefix_gravityflow_pdf_download_name( $name, $entry_id, $form_id ) {
    $safe_entry_id = absint( $entry_id );
    $safe_form_id  = absint( $form_id );

    return sprintf( 'workflow-%d-entry-%d-%s', $safe_form_id, $safe_entry_id, sanitize_file_name( $name ) );
}

Verification is simple: create a new test entry, move it to the PDF step, open the link from {workflow_pdf_download_link}, and check the actual downloaded filename. Rolling back is simple too: disable the snippet or remove the filter from the site-specific plugin. Do not use this code to control the server-side stored filename if your goal is specifically the download name. For copying the PDF to a separate location, the documentation points to a different action - gravityflowpdf_generated - but that moves into a more risky storage architecture.

What Not to Customize with Code

Do not use hooks to bypass access checks "just in case." The gravityflowpdf_download_authorized filter exists, but changes to authorization should be extremely targeted and thoroughly tested. If the goal is to give an external recipient temporary access, it is usually safer to use a signed link with a short expiration than to write your own access logic without an audit. Do not disable PDF deletion after email delivery just because it "feels safer." If the file stays on the server, that creates a new responsibility: controlling access, retention, backups, and deletion.

Fonts, Languages, and mPDF Considerations

PDF Generator uses mPDF, and that affects fonts, characters, tables, and complex layout. The official article on font issues explains that some large fonts are excluded from the extension archive. If the PDF loses characters or fails to generate at all, the likely cause is a missing font file. The timeline may show an error indicating that mPDF could not find a TTF file. For Chinese, Japanese, and Korean text, the documentation specifically mentions the need for Sun-ExtA.ttf.

The practical takeaway is this: even if the site only uses Latin and Cyrillic text, you should still test real names, addresses, and long text strings. If the site uses CJK languages, Arabic, Hebrew, mathematical symbols, or rare special characters, make font validation a separate stage. Do not launch the document workflow until you have generated a test PDF with the real languages and characters involved.

What to Do When Characters Are Missing

First, confirm the symptom. Compare the data in the Gravity Forms entry with the text in the PDF. If the characters are present in the entry but missing in the PDF, and the timeline points to an mPDF font error, the cause is almost certainly not the merge tags. The documentation recommends creating a custom fonts directory outside the plugin folder, for example inside wp-content, placing the missing font file there, and using the gravityflowpdf_mpdf hook to point mPDF to that directory. One important detail is to keep fonts outside the plugins directory so extension updates do not wipe out your changes.

Do not download random fonts from questionable websites. Use the source referenced in the documentation or a licensed font file approved for use on your site. After adding the font, rerun the PDF step for a test entry and check the timeline. If the error is gone but the text still looks poor, you may need a different font or a simpler template.

Customize mPDF Only When It Is Actually Necessary

The gravityflowpdf_mpdf hook lets you customize the mPDF instance. That is powerful, but it should not be the first tool you reach for. If the problem can be solved through template markup, simple headings, page breaks, or shortening a table, start there. mPDF customization makes sense for special requirements: an additional font directory, page numbers, header/footer, watermark text, or settings that cannot be configured through the standard PDF step.

Any mPDF customization should be tested on a separate form and documented alongside the workflow. A few months later, another administrator should be able to understand why the PDF behaves the way it does. In the PDF step Description, you can note that the appearance depends on a site-specific snippet, and in code comments you can include the form number and document purpose.

Common Gravity Flow PDF Generator Issues and Troubleshooting

Troubleshooting works best when you move from the workflow toward the PDF, not the other way around. First check whether the entry reached the correct step. Then check the condition, the template, permissions, email delivery, and only after that server-side mPDF errors. This order saves time: many "PDF is not working" cases turn out to be caused not by the generator itself, but by a condition, step placement, or user access issue.

The PDF Is Not Generated After Form Submission

Symptom: the entry exists, but the PDF file is unavailable, the email arrives without an attachment, or the user cannot see a link. A likely cause is that the workflow did not reach the PDF Generator step, the step was skipped by a condition, or it appears after a stage that has not completed yet. Open the workflow entry and the timeline. If the PDF step did not run at all, check step order, Condition, and Next Step. If the step ran and failed, review the error message in the timeline and the site log.

The fix depends on the cause. If the Condition is too narrow, create a test entry with the exact field value and verify the rule. If the step comes after an approval step, make sure the approval is actually complete. If the error is related to PHP or mPDF, temporarily simplify the template to just a few lines. Roll back the last change, not the whole plugin: the new condition, the new template, the new snippet, or the new form edit.

Merge Tags Appear in the PDF Instead of Data

Symptom: the document displays text such as {Email:2} or {workflow_note}. Possible causes include an incorrect merge tag, a deleted field, a tag inserted in an unsupported context, or a copy/paste mistake from another site. Open the template editor and insert the tag again through the merge tags menu instead of typing it manually. Check that the field exists in this form and that the field ID did not change after import.

If the tag refers to workflow data, make sure that data actually exists at the time of generation. For example, a note will not appear meaningfully if the relevant participant has not added the comment yet. The fix is to move the PDF step later or use a different field that is already populated.

The Email Arrives Without the Attachment

Symptom: the email is delivered, but the PDF is not attached. Check whether the setting to send the PDF by email is enabled in the PDF step itself, who is selected as the recipient, and whether the file exceeds your mail channel limits. If the email does not arrive at all, troubleshoot WordPress email and SMTP first, not PDF Generator.

For testing, create a small PDF template without images or long tables. If a small PDF attaches correctly but a large one does not, the issue may be file size or generation resource usage. Reduce the document, remove unnecessary images, split the process, or use a download link instead of an attachment.

The Download Link Opens for the Wrong User

Symptom: one user cannot download the PDF while another can open the file. If the link is unsigned, the system checks the current user's permissions. Verify whether the user is the assignee of the current step, whether they have the capability to view entries or the status page, and whether they are trying to open the link from a different account. If the link is signed, check the expires period and whether it has already expired.

Do not "fix" the problem by bluntly disabling access checks. For internal users, configure roles and capabilities correctly. For external recipients, use a signed link with a short lifetime. If special access is required, design it through a documented filter and a dedicated security test.

Characters Are Missing or mPDF Reports a Missing Font

Symptom: some characters are missing, the document is not generated, and the timeline shows an mPDF font error. This is typical of missing font files. Create a fonts directory outside the plugin folder, add the required TTF from a reliable source, and connect it through gravityflowpdf_mpdf as described in the documentation. Then rerun the step and test the same set of characters again.

If the site is multilingual, create a dedicated test entry with real names, addresses, and text in every relevant language. Do not rely on the word "test," because it does not validate font coverage.

The PDF Contains Extra Internal Fields

Symptom: the customer sees a system comment, a hidden field, or an internal status. The usual cause is an overly broad template, for example using {all_fields} without filtering. The fix is to replace the generic output with an explicit list of required merge tags. For internal and external recipients, it is usually better to create separate PDF steps or separate templates than to force one document to serve both purposes.

When Gravity Flow PDF Generator Is the Right Choice

Gravity Flow PDF Generator is worth using when the PDF is not just decoration for the form, but a documented outcome of the process. It fits well in scenarios where the entry goes through review, approval, clarification, or a conditional branch, and the document should appear only after the required step. In that case, you get more than a file. You get a managed part of the workflow, with conditions, scheduling, recipients, links, and access control.

Before launching it on a production site, verify the platform, dependency versions, PHP, email delivery, role permissions, the test form, the template, signed links, and fonts. Do not start with code customizations. First get a simple PDF generating reliably, then add conditions, email attachments, a clear filename, page breaks, and only then hooks. That order reduces risk and makes the process much easier to support.

If, after setup, you can see that the product covers your core scenario, you can download the ZIP archive and deploy it to a test environment or a production site according to your internal process. For complex PDF design, ready-made forms, or a standalone PDF system, compare alternatives in advance so you are not forcing a workflow extension to solve the wrong problem.

The best results come when the administrator thinks in terms of process: what data came in, who confirmed it, what document is needed, who is allowed to see it, and how the team will know it worked. If those answers are clear, PDF Generator becomes a clean final link in Gravity Flow rather than a source of random files in WordPress.