PandaDoc Approval Workflows: Setup Guide for Sales Teams

A PandaDoc approval workflow requires named approvers to sign off on a document before it can be sent to the client. You set approvers on a template or workspace, choose whether they review in sequence or in parallel, and the document sits in a Waiting for Approval state until every required approver clears it.

That is the mechanism. The design question, and the one this guide is really about, is which documents should trigger it. The approval workflows that work gate the exceptions: the deep discount, the custom terms, the deal above a value threshold. The ones that fail gate everything, turn a manager into a rubber stamp, and add a day of latency to proposals that were never risky in the first place. Teams already lose enough time to creation itself: manual proposal building was the top pain in 82 of the 129 sales calls we analysed, with 45 to 50 minutes per proposal a typical figure. An approval queue that adds another 24 hours on top of that, on every deal, is a self-inflicted wound.

Key takeaways

• PandaDoc approvals block a document from sending until named approvers clear it. Approvers are set per template or per workspace, as required or optional, in sequential or parallel order.
• Design rule: gate exceptions, not routine deals. Define what “standard” means for your team and let standard documents send without any approval step.
• Conditional approval rules fire only when a document meets defined criteria, such as a discount over threshold or a modified terms section. They are how you gate exceptions automatically instead of by rep judgement.
• Sequential routing gives a cleaner audit trail; parallel routing is faster. Default to sequential for financial sign-off and parallel when reviewers own different sections.
• Every approval gate needs an SLA and a named backup approver. An approver who never responds is a workflow design problem, not a people problem.
• Approval features sit on higher PandaDoc tiers, so confirm your plan supports what your design needs before you build it.

What is a PandaDoc approval workflow and how does it work?

An approval workflow in PandaDoc is a pre-send checkpoint built into the document lifecycle. When a document created from a template with approvers attached is ready to go, the rep clicks send and the document enters Waiting for Approval instead of going to the client. Each approver is notified, opens the document, and either approves it or rejects it with a comment. Only when every required approver has cleared it does the document actually send.

The building blocks are simple:

• Approvers are named users in your workspace. You attach them to a template so every document created from it inherits the approval step, which is the right way to do it: per-document approvers depend on the rep remembering to add them.
• Required vs optional controls whether a given approver can block the send. Required approvers must clear the document; optional approvers are notified and can comment but do not hold it up.
• Sequential vs parallel controls ordering. Sequential means approver B is only notified after approver A clears. Parallel notifies everyone at once.
• Rejection with comments sends the document back to the rep with the reason attached, so the fix-and-resubmit loop happens inside PandaDoc rather than over email.

One practical note before you design anything: approval features are tier-gated in PandaDoc, and the more conditional and rule-driven you want the workflow to be, the higher the plan you will need. Confirming that your plan supports your approval design is part of stage 2 of any sensible build, before templates are constructed around it.

The design rule: gate exceptions, not routine deals

The purpose of an approval workflow is risk control, and most proposals carry no meaningful risk. A standard-scope document at list price, built from an approved template, going to a mid-sized deal, does not need a second pair of eyes. It needs to be in the client’s inbox while they are still interested.

So the first artefact of a good approval design is not a workflow diagram. It is a written definition of a standard deal. Something like: discount within the normal band, deal value under the threshold that finance cares about, standard payment terms, no edits to the terms and legal sections. Any document that meets every criterion sends immediately, with no approval step at all.

Everything outside that definition is an exception, and exceptions are what your approvers should spend their attention on. This matters for two reasons. The obvious one is speed: the majority of your pipeline moves at full pace. The subtler one is signal quality. When a sales manager sees five approval requests a week instead of fifty, each one gets a real review. When every deal lands in their queue, they batch-approve on Friday afternoon and the workflow catches nothing. A gate that everything passes through is not a gate.

There is also a cultural effect worth naming. Reps who see that standard deals move without friction learn that the approval system exists to catch genuine exceptions, and they work with it. Reps who see every deal held up learn to route around the system, and then it catches nothing at all.

How to set up a PandaDoc approval workflow, step by step

Here is the build sequence we use. It assumes your template library already exists; if it does not, build that first, because approvals attached to templates nobody uses gate nothing.

1. Write the policy before touching settings. One page: what makes a deal standard, which exceptions need review, and who reviews each type. Get sales leadership and finance to agree on the thresholds. Every configuration decision that follows falls out of this page.
2. Name the approvers, and their backups. For each exception type, one accountable approver and one named backup. A gate with no backup is a single point of failure that will cost you a deal the week your approver is on holiday.
3. Attach approvers at the template level. Configure the approval step on each template that can produce an exception, so the workflow is inherited automatically. Do not rely on reps adding approvers to individual documents.
4. Add conditional rules where your plan supports them. Set the conditions so approval only triggers when a document actually crosses a threshold: discount depth, document value, or an edited content section. This is the mechanism that implements “gate exceptions” automatically; without it, you are relying on reps to self-declare exceptions.
5. Choose sequential or parallel per workflow. Sequential for chains where one sign-off depends on another, parallel where reviewers own different sections. Pick one per workflow and write the choice down; do not mix within a chain without a reason.
6. Set the SLA and the escalation path. Decide how long an approval may sit open, 24 to 48 hours is typical, and what happens when it lapses: reminder first, then reassignment to the backup.
7. Test with real documents before rollout. Run a sub-threshold document through and confirm it sends untouched. Run an over-threshold document through and confirm it stops. Reject one and check the rep gets the comment. The failure mode you are hunting is the standard deal that gets caught, because that is the one that erodes trust in the system fastest.
8. Train the team on the why, not just the how. Reps who understand that the workflow only fires on exceptions treat an approval request as meaningful. This belongs in the same role-based session as the rest of your rollout; it is a core part of the PandaDoc onboarding work we run with sales teams.

Conditional approvals: the rules that make exception-gating automatic

The difference between a policy and a system is enforcement. If your policy says “discounts over 15% need manager approval” but the workflow fires on every document, reps pay the tax on all deals. If the policy exists only in a handbook and the workflow fires on none, the risky deals sail through. Conditional approval rules are the enforcement layer: the approval step activates only when the document meets defined criteria.

The conditions that earn their keep in practice:

• Discount depth. The most common gate, and the most valuable. If your pricing lives in a proper pricing table with products, quantities, and discount fields, the discount is machine-readable and the rule can fire on it. This is one of the strongest arguments for building pricing as structured PandaDoc CPQ tables rather than typed-in numbers, which no rule can read.
• Document value. A total above the line where finance wants visibility routes to them; everything under it does not.
• Modified terms. A document where the standard terms or legal block has been edited routes to whoever owns legal review. Documents using untouched boilerplate skip it.

Keep the thresholds in as few places as possible, and review them quarterly. Watch two numbers: what percentage of documents trigger each rule, and how long approvals sit open. If a third of your proposals are hitting the discount gate, the threshold is set below your team’s normal trading range and you are gating routine deals again, just with extra steps.

Sequential vs parallel: which routing should you use?

Sequential routing notifies approvers one at a time, each after the previous one clears. It is slower, but the audit trail is unambiguous and no approver can assume someone else already checked the thing they skipped. Parallel routing notifies everyone at once. It is faster, but two approvers can make conflicting assumptions about who owns which question.

The default that serves most teams: sequential for financial chains, where the manager’s sign-off is a prerequisite for the director’s and the order carries meaning, and parallel where reviewers own clearly different sections, such as a solutions lead checking scope while an operations lead checks delivery dates. If you cannot say which section each parallel approver owns, they should probably be sequential.

The mistakes that turn approvals into a bottleneck

Four patterns account for most of the broken approval workflows we get called in to fix.

Approving everything. The workflow fires on every document because nobody defined “standard.” Approvers drown, latency lands on every deal, and reps start building documents outside the system to avoid the queue. The fix is the exception definition above, plus conditional rules to enforce it.

No SLA, no backup. A document sits in Waiting for Approval for four days because the one approver is at a conference. Every required approver needs a deadline and a named substitute, decided at design time, not discovered live on a closing deal.

Approvals as review. If approvers are routinely catching typos, wrong logos, and broken formatting, the template library is the problem, not the approval settings. Approvals are for policy exceptions; document quality should be solved upstream, in proposal templates locked down so reps cannot break them.

Policy buried in people’s heads. The threshold is “whatever feels big to the manager that week.” Reps cannot predict what will be gated, so they treat every deal as gated and pad their timelines to match. Written thresholds, enforced by rules, visible to the team.

When you need more than PandaDoc’s built-in approvals

PandaDoc’s approval workflow answers one question: is this document allowed to send? For many teams that is the whole requirement. It stops being enough when your approval logic depends on deal data that lives in the CRM rather than in the document, such as “any deal over $50k needs CFO sign-off regardless of what the document says,” or when finance wants gates enforced on the deal record itself.

At that point the pattern is two layers: document-content approval inside PandaDoc, and deal-level financial approval driven by CRM workflows, usually through the PandaDoc HubSpot integration with deal properties triggering the gates. We wrote a full architecture guide to that pattern, including discount write-backs, CFO gates, and bypass paths, in our post on PandaDoc and HubSpot approval workflows for enterprise teams. If you are a team of five with one approval rule, you do not need it. If you are a RevOps lead with a discount policy and an audit requirement, you do.

Approvals are also only one stage of a working system. Where they sit relative to templates, pricing rules, and CRM wiring, and why the order matters, is covered in our full PandaDoc implementation guide.

Frequently asked questions

Which PandaDoc plans include approval workflows?

Approval features are gated to PandaDoc’s higher tiers, and conditional, rule-based approvals sit above basic approver functionality. Feature packaging changes, so confirm the specific capability on PandaDoc’s current pricing page before you commit to a plan, and before you design a workflow around a rule your tier cannot enforce.

Can a rep still edit a document while it is waiting for approval?

Treat the approved version as final. If a document is edited after approval, the sign-off no longer describes what the client will receive, so your process should require re-approval after material changes. This is also why discount fields belong in locked pricing tables: it removes the quiet post-approval edit as a possibility rather than relying on policy to forbid it.

How many approvers should a document have?

As few as the risk justifies, usually one, sometimes two. Every additional required approver adds latency and diffuses accountability. If you find yourself wiring four approvers onto routine proposals, revisit your definition of standard: the volume should be going around the gate, not through a longer one.

What is a reasonable SLA for an approval?

24 to 48 hours for most commercial approvals, shorter if your sales cycle is fast. The SLA only means something with an escalation behind it: a reminder when it lapses and reassignment to the named backup shortly after. An SLA nobody enforces is just a wish.

Should approval workflows apply to renewals and small deals?

Usually not, and this is the “gate exceptions” rule doing its job. A renewal at standard terms and a small deal at list price carry minimal risk; let them send. The moment a renewal carries a repriced discount or modified terms, the conditional rules catch it like any other exception.

Get the approval layer designed properly

An approval workflow is a policy encoded in software, and it is only as good as the policy. The teams that get it right write down what standard means, gate only the exceptions, give every gate an SLA and a backup, and test that routine deals flow through untouched before go-live.

If you want that designed and built by a team that has done it across 100+ PandaDoc implementations, our PandaDoc onboarding service covers approval design as part of the rollout, from the policy page to the tested workflow. Book a call and we will map your exception types, thresholds, and approvers in the first session.