PandaDoc and Salesforce both hold the truth about a deal — the Opportunity holds the forecast, the document holds what the customer actually signed. When the two are not wired together, reps re-key pricing, managers chase status, and the pipeline reports a number no contract supports. Twopir architects the connection between them: tokens and templates, quote and line-item sync, approval routing, and status writeback. One deal, one set of numbers, from first quote to signature.
Trusted by 500+ organizations — including revenue, sales operations and legal teams running document generation, quoting and e-signature on Salesforce and HubSpot with Twopir Consulting.
Built for Salesforce Revenue Teams
Teams that run Salesforce as the system of record and PandaDoc as the document engine usually hit the same six frictions within a quarter. Every one of them is an architecture gap, not a user-training problem. The longer both run unconnected, the wider the gap.
Proposals and contracts carry customer names, pricing and terms that were correct when the document was built. The Opportunity keeps moving. Nothing reconciles the two, so the CRM and the signed agreement quietly disagree.
Toggling to check whether a document was opened, copying pricing across, updating the stage by hand. It is minutes per deal, hundreds of times a quarter, and every hop is a chance to mistype a number that ends up in front of a customer.
A buyer signs in PandaDoc. Somebody still has to open Salesforce and move the Opportunity to Closed-Won. Until they do, the forecast is wrong — and end-of-quarter is exactly when nobody has time to do it.
Bidirectional sync means both sides can change. If a rep edits the deal value in Salesforce while the buyer selects different options in the quote, the two systems hold different totals and no rule says which one wins.
Names, emails and amounts map in minutes. Multi-select picklists, formula fields, cross-object lookups and polymorphic fields are where template population quietly fails — usually as a blank line in a contract nobody checked.
The native integration surfaces documents on Opportunities, Accounts and Contacts. The moment your process runs on a custom object — a renewal, a project, an order — you are outside what configuration can reach.
PandaDoc is a document automation and e-signature platform: you build reusable templates with variables, roles and pricing tables, generate documents from them, route them for internal approval, send them for signature, and track what the recipient did with them. PandaDoc is made by PandaDoc, not by Salesforce, and it keeps its own data model, its own permissions and its own plan tiers. Its native Salesforce integration is what makes the two behave as one system.
Three things get confused on pages like this, so we will separate them plainly. PandaDoc provides the capability — templates, variables, quote building, approval rules, e-signature, identity verification, document analytics and a REST API. Salesforce remains the system of record for the customer, the Opportunity and the forecast. Twopir designs and builds the connection between them — the field mapping, the sync rules, the approval logic, the writeback, and the custom development where the native connector runs out. We implement PandaDoc; we are not PandaDoc.
It is a fit when documents are a bottleneck in a deal that already lives in Salesforce: proposals, quotes, order forms, statements of work, renewals, NDAs. It is a poor fit when the real problem is upstream — a data model that cannot describe your products, or a sales process nobody follows. Document automation makes a clean process faster and a broken process faster at being broken, which is why every engagement starts with the process, not the template.
We work with growing, mid-market, and enterprise organizations that need help with complex CRM implementations, integrations, and business system challenges. For PandaDoc on Salesforce that usually means a revenue team of twenty to a few hundred sellers, a real product catalogue, and an approval chain that somebody in finance cares about.
These are three different services bought by three different people, and almost no competitor page tells you where one ends and the next begins. Here is the line.
Standing the integration up properly the first time — the work that decides whether anyone trusts the system six months later.
Making the platform express your commercial rules — done inside PandaDoc's and Salesforce's own surfaces, with no code to maintain.
Everything the native connector cannot reach. This is software development, scoped and maintained as such.
| Requirement | Implement | Configure | Build on |
|---|---|---|---|
| Generate a proposal from an Opportunity | Yes — core scope | Template design | — |
| Write document status back to the Opportunity | Yes — core scope | Status-to-stage rules | — |
| Sync a quote to Opportunity Products | Connector enabled | Yes — mapping and rules | Only for non-standard pricing logic |
| Route approvals above a discount threshold | — | Yes — rules engine | — |
| Generate from a custom object | — | Not reachable | Yes — API build |
| Bulk-generate renewals on a schedule | — | Not reachable | Yes — API build |
| Embed signing inside your own portal | — | Not reachable | Yes — JavaScript SDK |
Most engagements are Implement plus Configure. Roughly one in three eventually needs a small Build-on component, and it is far cheaper to know that during design than after go-live.
The boundary, in one sentence: configuration ends where the native integration's object surface ends. Documents surface on Opportunities, Accounts and Contacts — generating from a custom object, enforcing logic the rules engine cannot express, or embedding the signing experience in your own application is API work, not a settings change. We will tell you which side of that line you are on before you buy, not after.
Six capability areas, each one a thing we configure or extend on your behalf — not a feature list copied from the vendor.
The layer that decides whether a document is right before anyone reads it. We map Salesforce fields to PandaDoc variables and roles, then build templates that assemble themselves.
Where the commercial rules live. PandaDoc's Quote Builder and pricing tables can carry the catalogue, the discounting guardrails and the optional products.
Approvals configured once on the template so every document created from it follows the same path — rather than a policy nobody enforces.
Signing inside the deal flow, with the level of identity assurance the agreement actually warrants.
PandaDoc records which sections a recipient opened and how long they spent there. Surfaced in Salesforce, that becomes a follow-up signal instead of a curiosity.
The unglamorous layer that keeps a document platform from turning into a shared drive with signatures.
A logo row proves nothing. For every connection below: both platforms named, the business purpose, and what data actually moves which way.
Account, Contact and Opportunity fields populate document variables at creation time, so the customer detail on a contract is whatever the CRM held that moment — never retyped.
Document state (draft, sent, viewed, completed, expired), the completion timestamp, the signed PDF and the document link write back to the Opportunity in near real time.
Pricing-table and Quote Builder line items sync with Opportunity line items in both directions, including added, removed and optional products — with a documented rule for which side holds the authoritative total.
Approval status and approver identity land on the deal record, so a manager reviewing the forecast can see whether a discounted quote ever cleared its gate.
For everything the connector does not reach: document creation from custom objects, bulk generation, and event-driven sync where a webhook fires your middleware on a status change.
Event-triggered flows for narrow jobs on lighter plan tiers: one trigger, one action, no document analytics. Useful, and not a substitute for the native connection.
Signed quote to invoice without a re-key: the accepted line items drive subscription or invoice creation in the billing platform, and payment status returns to the CRM.
Slack or Teams alerts on signature, stall or approval request, routed to the owner rather than broadcast to a channel nobody reads.
Five phases, one accountable team. The shape below is the delivery model behind the eight-week engagement in the outcomes section — timelines move with document complexity and how many approvers have an opinion.
We map every document type from first quote to signed order, catalogue each field that must populate, and find the approval steps and downstream systems that touch a document. On the engagement below this produced 14 distinct data points to auto-populate and three conditional content scenarios.
We design the token map between Salesforce objects and PandaDoc variables, decide which system owns the authoritative deal value, and specify the status-to-stage rules. Complex field types get a transformation plan here rather than a surprise in UAT.
We build the templates, pricing tables and conditional sections, then set the approval routing and governance. One template serves several deal types, so the library stays small enough for somebody to own.
We connect the systems, configure the two-way sync, and test every handoff — including the failure paths. Where the native connector stops, this is where the API component is built and instrumented.
Structured rollout with training, a parallel run and live support through the first cycle, then a review against the baseline from Phase 01. We stay accountable after go-live, when the system meets real quarter-end volume.
Real engagements, with the scope each number was measured against.
40–150 sales users · 500+ documents per month · delivered in 8 weeks across 5 phases
Proposal creation used to take a rep 45 minutes of copying data, fixing formatting, and hoping nothing was wrong by the time it reached the customer. Now they click one button inside Salesforce and a fully accurate, branded document is ready to send in under a minute. The eSignature alone has cut our average close cycle by days.
Connecting the quote, the signature and the subscription into one flow
Engagement scope: the accepted PandaDoc quote drives subscription creation in Chargebee, and billing status returns to the Salesforce Opportunity, so sales, finance and the customer read the same agreement. Outcome metrics for this engagement are being confirmed with the client before publication.
If more than one of these describes your quarter, the architecture is the problem — not the effort your team is putting in.
You own the number and the systems behind it. You need the forecast to reflect signed agreements, not optimistic stage updates, and you need to stop paying for the reconciliation.
You inherited a PandaDoc connection somebody enabled and nobody designed. Field mappings are partial, the template library has grown to sixty, and every new product breaks something.
Your reps spend hours a week building documents instead of selling, and deals sit unsigned because nobody knows the buyer opened the pricing page three times.
You need discounts to clear an approval gate before the customer sees them, and you need the signed version to be findable in seconds during an audit.
You want to know, before committing budget, exactly which requirements the native connector covers and which ones mean maintaining code.
PandaDoc is installed, adoption is patchy, and nobody can say whether it shortened anything. That is an optimization engagement, and it is usually a short one.
PandaDoc work goes wrong at the Salesforce end far more often than at the PandaDoc end. That is the half most document specialists are weakest on.
Field-level security, sharing rules, record types, polymorphic lookups and API limits are where these projects actually fail. We design the Salesforce side properly, then connect the document layer to it.
Before you buy. The comparison table above is the same one we walk through in discovery, and we would rather lose a deal than sell configuration for a requirement that needs code.
Document automation is rarely the only gap. We have connected quoting, signature, billing and subscription systems on the same engagement, so the handoffs are designed, not improvised.
With a 40+ person team and 500+ clients across the US, Canada, UK, UAE, Australia and New Zealand, over 12+ years of CRM delivery.
Every build is tested against your real documents and your real approval chain before it touches production. No template library assembled from somebody else's business.
PandaDoc ships changes — a new editor, new AI capability, plan-tier moves — and Salesforce ships three releases a year. Managed support keeps the integration current instead of slowly rotting.
The questions that actually decide whether this is the right project — answered straight.
Yes. PandaDoc publishes a native Salesforce integration built on Salesforce Lightning that embeds document creation, sending and tracking inside Salesforce records, and supports two-way synchronisation: Salesforce data populates PandaDoc templates, and document status writes back to the Opportunity. The integration and its CPQ package are gated to PandaDoc's higher plan tiers and require a Salesforce edition with API access. We confirm your exact licence position during discovery, because the gating changes and it determines what is possible without custom development.
Implementation is standing the integration up: package install, OAuth and permissions, component placement, token configuration and your first working templates. Customisation is expressing your commercial rules inside the platform — pricing tables, approval thresholds, conditional content, status-to-stage rules — and it is still configuration, with no code to maintain. Custom development is a third thing: generating from custom objects, bulk runs, embedded signing, and anything needing the REST API. Most teams need the first two; about one in three eventually needs a small amount of the third.
Not through the native integration. The connector surfaces documents at the Opportunity, Account and Contact level. If your process runs on a custom object — a renewal, a project, an order — generating from it requires API development against PandaDoc's REST API, with your own service handling authentication, field mapping and error recovery. It is very achievable and it is a development project with a maintenance cost, which is why we scope it explicitly rather than describing it as a configuration option.
Both systems can write, so bidirectional sync makes conflicting updates possible. The native integration handles status sync automatically, but pricing conflicts between a PandaDoc quote and Salesforce Opportunity line items need an explicit operational rule about which system holds the authoritative deal value. Deciding that rule is a design decision we make with you in Phase 02 — not something to discover at quarter-end.
PandaDoc CPQ for Salesforce is designed as a lighter path for teams that need guided selling, pricing rules, conditional approvals and document generation in one workflow without a large CPQ implementation. Teams with very complex configurations — thousands of interdependent SKUs, multi-currency pricing across many regions — are usually better served by a dedicated enterprise CPQ platform. We assess the catalogue's real complexity before recommending either, and we have no commercial reason to push you toward the bigger project.
The engagement referenced in the outcomes section above ran eight weeks across five phases, covering four document types for a team of 40 to 150 sales users generating 500+ documents a month. A single-template rollout on a clean Salesforce org can be considerably shorter; a multi-entity build with CPQ, custom-object generation and a billing integration is longer. The variables that move the timeline most are the number of document types and how many people hold approval opinions.
A Salesforce System Administrator with the access to install a package and approve a Connected App, a PandaDoc workspace admin, somebody who owns the commercial rules — usually sales ops or finance — and a small group of reps for UAT. The heaviest ask is Phase 01, where we need your real documents and an honest account of the approval process as it is actually practised.
Usually, yes, and that is the more common engagement. We audit the current token mapping, template library, approval rules and writeback configuration against how the team really works, then fix what is broken and retire what is unused. Rebuilding from scratch is the right call only when the Salesforce data model underneath has changed so much that the original mapping no longer describes the business.
Bring us your real documents and your real approval process. We will show you which parts the native Salesforce connector covers, which parts need configuration, and which parts genuinely need development — before you commit to anything.
12+ years · 500+ clients · 40+ consultants · Salesforce Partner · HubSpot Partner
