PandaDoc Forms: The Complete Guide to Self-Serve Documents

PandaDoc Forms turn a template into a self-serve document: you publish a link or embed the form on your website, the respondent fills in their details, and PandaDoc generates a ready-to-sign document automatically, with no rep involved. Forms are available on Business and Enterprise plans, each generated document uses one usage credit, and as of late 2026 the feature is mid-migration: standalone forms are being folded into templates as a workflow step, which changes how new forms are built.

That migration is the reason to read a current guide rather than a two-year-old one. Most of what is written about PandaDoc Forms describes the classic Forms section, which PandaDoc has stopped accepting new forms into on migrated accounts. This guide covers both experiences, verified against PandaDoc’s current documentation: how classic forms behave while you still have them, how the new template-based form step works, and the decision that matters more than either, which is knowing when a form is the right delivery mechanism at all. The context for that decision is volume: manual proposal creation was the top pain in 82 of the 129 sales calls we analysed, and when a document is standardized enough, a form removes the rep from the loop entirely rather than just making the rep faster.

Key takeaways

• A form is a template exposed to the world: respondents fill in fields through a web page, and every submission generates a document that can be signed immediately. Share it as a direct link or embed it on your site.
• Forms are gated to Business and Enterprise plans, and every document generated from a form consumes one usage credit. Drafts, views, and abandoned forms cost nothing. One form can generate at most 50 documents in 5 minutes and 300 in one hour.
• PandaDoc is migrating forms into templates account by account. Existing public links and embed codes keep working through the migration, but on migrated accounts a new form is built as a “Fill in document details” workflow step on a template, not from the Forms section.
• The migration fixes the classic experience’s biggest limitation: classic forms only support role variables, while the new form step maps custom questions to any variable in the template, supports dropdowns and validated field types, and can name the generated document from the answers.
• A form beats a rep-sent proposal when the document is standardized, the volume is high, and the data comes from the client: think intake agreements, standard service sign-ups, rental and booking paperwork. Negotiated, priced-per-deal proposals should stay rep-sent.

What a PandaDoc form is, and what it is not

PandaDoc gives you three ways to get a document in front of someone, and teams regularly pick the wrong one because the names are close.

A template is the internal master: a rep creates a document from it, fills or inherits the deal data, and sends it to named recipients. A bulk send pushes one document to a list of recipients you already have, each getting their own copy. A form inverts the direction: you do not know who the recipient is until they show up. The respondent finds the form through your website or a shared link, enters their own details, and the document generates itself.

That inversion is the whole value. In the classic experience the person who opens the form becomes the primary recipient, enters their email, first name, and last name behind an invisible reCAPTCHA check, gets walked through each field, and finishes the signing flow in one sitting. If the document needs a co-signer, an optional secondary recipient can be added, and the primary recipient enters that person’s details: the co-signer then receives an email invitation rather than needing to find the form themselves. Signing order can be set when there are several.

Forms support real document machinery, not just flat fields: content blocks, fillable fields, pricing tables, the quote builder, and file-collection fields all work inside one. You can apply document auto-numbering so every generated agreement carries a sequence number, and download responses as a CSV.

The 2026 migration: forms are moving into templates

PandaDoc is retiring standalone forms gradually, account by account, with an email before each account migrates. What changes and what does not, per PandaDoc’s own migration notes:

• Existing forms keep working. Each one is copied into a connected template with its content, fields, and settings. Public links and embed codes continue to work, and anyone who opens an old link is redirected to the new form experience automatically. You do not need to touch your website.
• The Forms section is on borrowed time. It still appears in the left navigation and lists existing forms, but new forms can no longer be created from it on migrated accounts, and PandaDoc plans to remove the section in a future update.
• A form is now a workflow step. On a migrated account you open a template, add a “Fill in document details” step to its workflow, and configure that step as the form. Each template can carry one such step.
• Pricing does not change. Business and Enterprise gating and the one-credit-per-generated-document rule carry over unchanged.

Two classic-experience capabilities were still catching up at the time of writing: CSV response download and pre-filling forms via embed parameters are listed as in development for the new experience. If either is load-bearing for your process, verify its status before you migrate a workflow that depends on it.

If your account has not migrated yet, everything in the classic section below still applies. If it has, skip to the new experience.

Classic forms: how they work while you still have them

On a not-yet-migrated account, forms live in their own section. The account owner enables the eForms add-on from the Marketplace and selects which workspaces get it; after a refresh, Forms appears in the left panel. From there, the +Form button creates a form from an existing template, importing the template’s roles, with the first role becoming the primary recipient. You can also open any template and choose “Create form from template” from its three-dot menu.

The constraint that shapes classic form design is the variable rule: classic forms only support role variables, the ones that fill from the signer’s own contact details. Custom variables, the ones a rep would normally fill at creation, do not work on forms, and neither do variables in the form’s title. Our PandaDoc variables guide covers the type system in full, but the practical consequence here is simple: in the classic experience, anything you want personalised beyond the respondent’s name and contact details has to be a fillable field in the document itself, not a variable in the standing copy.

Publishing is a three-state switch. A Draft form is built but not fillable. Publish it and it goes Active: the “Get code” option then gives you either a direct link to share or embed code for your website. To edit a live form you unpublish it first, which sets it Disabled and shows respondents an unavailable notice; after editing, republish, and the embed code stays the same, so nothing on your site needs redeploying. One nuance worth checking after every edit: a form embedded on your website but left unpublished simply cannot be filled, and nothing on your page will look broken. The status lives in PandaDoc, not in the embed.

Pre-assignment is allowed for every role except the primary recipient, which by definition is the unknown person who opens the link. Recipient groups are not supported in forms at all.

The new experience: the Fill in document details step

On a migrated account, the build starts from the template. Open it, go to the workflow sidebar, add a step, and choose “Fill in document details.” PandaDoc generates a first draft of the form automatically: each role gets a contact block (email, first name, last name, company), and every variable in the template becomes a question whose label derives from the variable’s name. From there the form editor lets you rework it: retype labels, reorder, make fields optional, and add fields with real types, short and long text, number, email, phone, date, multiple choice, checkboxes, and dropdowns, plus title and image blocks for layout.

This is where the new experience overtakes the old one. Three capabilities classic forms never had:

• Custom questions mapped to variables. Any answer can fill any variable placed anywhere in the template. The old role-variables-only limitation is gone, which means standing copy can finally be personalised from form answers: project names, site addresses, chosen service tiers.
• Dropdowns on any variable. Turning a free-text question into a selection list is one setting, which keeps the generated documents consistent: a “service type” dropdown produces three clean values instead of thirty spellings.
• Dynamic document names. Variables work in the template name, so submissions arrive as “Service Agreement, Acme Corp” instead of fifty identical titles.

Sharing is the chain-link icon at the top of the template, with the tooltip “Share as public form.” The Generate document via link panel gives you the public link or the embed code, and, when the template has several roles, a dropdown to pick which role fills the form. One person now completes the entire form, including contact details for any other roles, before the document generates; the classic relay where a secondary recipient filled their own part separately is gone. Generated documents land under Documents in a folder named after the template.

Access control moved from publish/unpublish to a toggle: “Anyone with the link can respond.” Switch it off and the link immediately shows a no-longer-accepting-responses message, while your own team can still use the template internally; documents already submitted are unaffected.

Two honest caveats on the new experience. First, the public form is not compatible with creating documents from a CRM: a form submission starts from the template, not from a deal record, so CRM-fed tokens are not doing the filling here, the respondent is. Second, the generated document is only auto-sent for signing when the template is fully resolved. An approval workflow on the template, a half-configured payment, unfilled variables, unassigned fields, missing recipients, or a required smart content block with pre-selected content will each stop the auto-send, and the submissions pile up as drafts someone has to notice. Resolve all of those before the link goes on your website, and submit a real test entry yourself to prove the whole path runs unattended.

When a form beats a rep-sent proposal

A form is the right mechanism when three things line up: the document is standardized, the data comes from the client, and the volume justifies removing the human. One fleet services company we worked with is the cleanest anonymous example: proposal creation was so cumbersome that only around 5 proposals a month were going out, and the team said outright they would send more if it were easier. Part of that build was a form, because a meaningful slice of their paperwork was standard enough that the client could initiate it themselves, with a unified template doing the formatting and the maths.

The pattern generalises. Good form candidates: intake and onboarding agreements, standard service sign-ups at published prices, rental and booking paperwork, waivers, credit applications, anything where the questions are the same every time and the answers belong to the client. Bad form candidates: anything negotiated, anything priced per deal, anything where the sales conversation is part of the value. Teams spending 45 to 50 minutes per proposal usually need the template and variable layer fixed first, because their documents are deal-specific; the form is the further step for the subset of documents that are not deal-specific at all.

There is also a quiet operational benefit: a form cannot go off-brand. The respondent never touches the layout, so the lock-everything discipline from our branded proposal templates guide is enforced by the medium itself. And because pricing tables and the quote builder work inside forms, a standard-rate agreement can carry live, calculated pricing rather than a typed number, with the same guardrails covered in our pricing tables guide.

Mind the meter, though. One credit per generated document is irrelevant at 20 submissions a month and a real line item at 500, and the 50-per-5-minutes and 300-per-hour generation caps make forms the wrong tool for burst-scale document generation; that is API territory. Where a form sits in the wider build, alongside templates, integrations, and the catalog, is the scoping question a PandaDoc implementation answers before anything gets built.

Frequently asked questions

Which PandaDoc plans include Forms? Business and Enterprise. On classic accounts the account owner also has to enable the eForms add-on from the Marketplace per workspace before the Forms section appears. Each document generated from a form uses one usage credit on top of the subscription, so forecast credit usage against your expected submission volume, not your plan price.

Do my existing form links break when PandaDoc migrates my account? No. PandaDoc copies each form into a connected template, existing public links and embed codes keep working, and respondents are redirected to the new experience automatically. What does change is where you manage it: the form becomes a workflow step on the template, and new forms can no longer be created from the Forms section.

Can a form fill variables in the document? In the classic experience, only role variables, the signer’s own contact details; custom variables and title variables are unsupported. In the new template-based experience, yes: every form question maps to a variable you can place anywhere in the template, and variables can even name the generated document.

Can someone sign and pay through a form? Yes. Forms run the full signing flow, and payment collection is supported, but in the new experience a template with a half-configured payment (a missing gateway or payer) will stop generated documents from being auto-sent. Configure the payment completely and run a test submission end to end before publishing the link.

Should I use a form or just send proposals from templates? Use a form for standardized, client-initiated paperwork at published terms; keep rep-sent, template-based proposals for anything negotiated or priced per deal. Most teams need both, and the split falls out naturally in scoping: if a rep would copy-paste the same document for the hundredth time, that document wants to be a form.