PandaDoc turns a Salesforce record into a finished, signable document. Getting there takes more than installing the package — templates have to match your data model, pricing has to survive CPQ, approvals need real owners, and signed status has to land back on the record your team actually works from. We design, build, integrate and support that whole path.
Trusted by 500+ organizations — including real estate, legal and professional-services teams running their document workflows on Salesforce with Twopir Consulting.
What We Deliver on PandaDoc
Almost nobody buys document automation because documents are interesting. They buy it because the last mile of the deal — the quote, the contract, the signature — is the slowest, most error-prone part of a process everything else already runs cleanly. These are the six failures we find most often.
A rep opens last quarter's proposal, swaps the names and the numbers, re-checks the discount and emails a PDF. Every document is a small manual project, and the time lands on your most expensive people at the worst moment in the deal.
Legal entity name, billing address, term dates, quantities and pricing already exist on the Salesforce record. Re-typing them into a document is exactly where wrong entity names, stale addresses and totals that do not match the quote enter your contracts.
Every region, product line and deal size grows its own file, stored in somebody's drive. Nobody can say which version is current, and legal has no mechanism to enforce the clause set that was actually approved — only to find out afterwards that it was not used.
Discount sign-off, legal review and countersignature run on forwarded mail and message threads. There is no durable record of who approved what, and nothing stops a document reaching the customer before the approval it needed ever arrived.
The document goes out from somebody's inbox, so managers ask for status in stand-up. The opportunity record cannot tell you whether the contract was opened, viewed, signed — or has been sitting untouched for nine days with a forecast still built on it.
A process that holds together for five reps and one product line breaks at fifty reps, three regions and a CPQ-driven price book. Each new hire adds coordination rather than throughput, and onboarding gets longer every quarter.
PandaDoc is a document automation and electronic signature platform. PandaDoc for Salesforce is its managed AppExchange package: once installed, a Lightning component sits on the Opportunity, Quote, Account, Contact, Lead or a custom object, and a user can generate a document from a template with Salesforce field values already merged in, send it for signature, and see every document ever created against that record.
The prerequisites are worth knowing before anyone signs a subscription. The package is installed from the AppExchange by a Salesforce administrator and ships its own permission sets for admins and users. PandaDoc lists a Business or Enterprise annual plan alongside a Professional, Enterprise, Unlimited or Developer edition of Salesforce. Salesforce CPQ support is a separate PandaDoc CPQ package that cannot be installed until Salesforce CPQ itself is in the org — a sequencing detail that has delayed more than one go-live. Current requirements live in PandaDoc's own Salesforce integration documentation and on the PandaDoc for Salesforce AppExchange listing, and we confirm them against your org during assessment rather than quoting them from a brochure.
The platform is the easy half. What decides whether a PandaDoc implementation works is everything around it: whether your data model can supply a clean merge value for every field a contract needs, whether pricing survives the trip from CPQ into a document, who owns each approval, where the signed file has to land, and what gets written back so the CRM stays the system of record. That is the work we do.
We help growing and mid-market companies solve complex CRM, integration, and business system challenges — and on this page that means revenue operations leaders, CRM managers, Salesforce administrators and architects, legal and contract owners, real-estate transaction teams and the document-operations people who inherit whatever the rest of the business ships.
| Layer | What it does | Who owns it |
|---|---|---|
| Salesforce | Holds the record of truth — accounts, contacts and roles, opportunities, quote lines, custom objects, and every field a document merges from. | Your team, with Twopir on data model and field design |
| PandaDoc | Generates the document from a template, merges the Salesforce values, runs approvals, collects a legally binding signature, and reports status. | PandaDoc — this is native product capability |
| Templates & tokens | Decide what each document says, which clauses appear under which conditions, and which CRM field fills which value. | Twopir, with your legal and revenue leadership |
| Integration & automation | Decide when a document is created, who has to approve it, where the executed file is stored, and what is written back to the record. | Twopir |
| Adoption & support | Decide whether any of it is still being used twelve months after go-live, and whether it survives a new product line or a CPQ change. | Twopir with your admin team, under a support agreement |
These are three different projects with three different budgets, and conflating them is how PandaDoc engagements overrun. Here is where we draw the line: configuration is everything PandaDoc and Salesforce can be set to do declaratively; custom development begins the moment a requirement needs code, an API call, or an object the package does not know about. We tell you which side a requirement falls on during assessment, not during the build.
A first deployment, taken from an empty org to a team that uses it daily. This is the engagement for organizations buying PandaDoc now, or already holding licences nobody has rolled out.
PandaDoc is live and it is not working. Documents are wrong, templates have multiplied, approvals are ignored, or adoption stalled after the first month. We rebuild the parts that are failing.
The requirement has outgrown configuration. This is Apex, Flow and API work built around PandaDoc — and we will tell you honestly when a requirement does not justify it.
Six workstreams. Most engagements need four of them; a regulated or CPQ-driven business usually needs all six.
We rebuild your live documents as governed PandaDoc templates: one master per document type, with conditional content handling the regional, product and deal-size variants that used to justify a separate file.
Every token needs a field that is populated, correctly typed and reliably present. We map each one to the Salesforce object it comes from and fix the gaps before they show up as a blank line in a signed contract.
Approval rules that reflect your delegation of authority — by deal value, discount depth, document type or entity — so the exception path is explicit and a document cannot reach a customer ahead of its sign-off.
We configure the signing experience and the evidence behind it, then agree with your legal team which document types need which level of assurance — not every agreement needs the same one.
Quoting is where document projects usually break. We map CPQ quote lines into PandaDoc pricing tables, confirm which sections sync back to the opportunity, and make the totals on the page match the totals in the CRM.
Document status becomes reportable CRM data: what is out, what is stalled, what was signed and how long each stage took. Then somebody has to own it — usually us, under an agreed support model.
A document workflow is an integration problem wearing a template. These are the connections we design, what moves across each one, and in which direction.
Account, contact, opportunity, quote and custom-object values merge into the template at generation time, so the document is built from the record rather than from a rep's memory of it.
Document status, timestamps and the completed file flow back onto the record. Sales managers read signature progress in the pipeline instead of asking for it, and forecasts stop relying on optimism.
CPQ quote lines populate the PandaDoc pricing table, and the document value follows the quote's net amount. Where a quote section is set not to sync, its products stay out of the opportunity — a behaviour worth designing deliberately.
Where the package stops, the API starts: documents created from a Flow or Apex trigger, status events pushed to your systems, and signing embedded in a portal or community your customers already use.
Executed agreements are routed to where your retention policy expects them — Salesforce Files, SharePoint, Box, Google Drive or a legal DMS — with the CRM keeping the link rather than a second copy.
Signer authentication and identity checks attach to the document, and the resulting audit evidence is stored against the customer record — which is what makes a KYC or AML review a query rather than an archaeology project.
Where marketing and customer success run on HubSpot, documents can be generated there too. Our PandaDoc and HubSpot implementation guide covers that side in detail.
Plenty of orgs already run Nintex DocGen for Salesforce or Conga. We have deployed PandaDoc alongside both — one handling high-volume internal generation, the other owning the customer-facing signature path.
Six phases, one continuous engagement. A focused first deployment — one or two document types, a clean data model — typically runs a few weeks; a multi-entity, CPQ-driven rollout with legal review and migration runs considerably longer. We scope the range honestly at assessment rather than quoting a number this page cannot know.
We sit with the people who make documents today, watch the real process, and collect the documents themselves — including the ones nobody admits to using.
Current-state assessment of the org and the data behind every merge field, then a solution architecture that says which requirements are configuration and which are custom.
Package setup, permissions and the template set — built in a sandbox against your real records, not sample data, so the failure modes surface while they are still cheap.
Triggers, approval routing, write-back, storage and any custom development. This is where the document stops being a file somebody makes and becomes part of the process.
Scripted UAT against edge cases and real deal shapes, then role-based training — reps, approvers and admins each need a different half-hour, not the same one.
A staged go-live, then the weeks after it: watching real usage, fixing what the pilot did not reveal, and tuning templates as products and terms change.
| Stage | What happens | Why it matters |
|---|---|---|
| 1 · Business & requirements discovery | We inventory every document your business produces, who produces it, from which record, and how often — then rank them by volume and pain. | Automating the wrong three documents first is the most common way a PandaDoc project stalls before anyone sees value. |
| 2 · Current-state assessment | A review of the Salesforce org behind the documents: objects, fields, record types, existing automation and the data quality of every field a contract will merge. | A blank field in a template is a blank line in a signed contract. Nearly every merge failure traces back to data, not to PandaDoc. |
| 3 · Solution architecture | We decide which objects documents generate from, how related records supply their values, where the configuration boundary sits, and what the integration surface looks like. | This is the document that keeps the project honest. It fixes scope, and it is where the configure-versus-build decision is made and agreed. |
| 4 · PandaDoc configuration | Package installation, permission sets, licence assignment, workspace and role setup, and placement of the Lightning component on the right page layouts. | Getting permissions and layout placement right on day one avoids the support queue filling with people who cannot see the button. |
| 5 · Template & document design | Your live documents are rebuilt as master templates with conditional content, a content library for approved clauses, and pricing tables that match how you actually quote. | One governed template with conditions replaces the dozen near-identical files that made version control impossible. |
| 6 · Salesforce integration | Token-to-field mapping across standard and custom objects, related-record strategy, and — where CPQ is in play — quote-line and pricing-table mapping. | This is the step that eliminates re-keying, and with it the category of error that makes legal distrust the whole system. |
| 7 · Workflow & automation | Generation triggers, approval rules by value and document type, signing order, reminders, escalation, storage routing and status write-back. | Automation is what turns a faster document into a faster process. Without it you have simply moved the manual work somewhere newer. |
| 8 · Customization | Apex, Flow and PandaDoc API work for the requirements configuration cannot reach — document packages, embedded signing, custom objects and downstream handoffs. | Kept deliberately small and documented. Custom code is the part of the build that someone has to own for years, so it should earn its place. |
| 9 · Testing & validation | Scripted UAT across real deal shapes and edge cases: missing data, multi-signer orders, rejected approvals, amended pricing and cancelled documents. | Document bugs are visible to customers. A contract with the wrong entity name costs more credibility than a broken report ever will. |
| 10 · User training | Role-based sessions for reps, approvers and administrators, with a written runbook covering the failure cases each role will meet. | Adoption is the real deliverable. A perfectly configured system nobody uses is indistinguishable from no system at all. |
| 11 · Deployment | Staged go-live — usually one team and one document type first — with a rollback position and a named owner for the first two weeks. | A phased cutover contains the blast radius. Where documents are revenue-critical, that matters more than finishing a week earlier. |
| 12 · Support & optimization | Template changes as products and terms move, new document types, approval-rule tuning, and reporting on where documents still stall. | Document systems drift the moment pricing or legal language changes. Ownership after go-live is what keeps the second year working. |
Document automation pays back fastest where volume is high, the format is repetitive, and the data already exists in the CRM. These are the workflows that fit that description.
Reservation forms, sale and purchase agreements, and handover documents generated from the property and buyer records, then signed and tracked — the workflow behind our real-estate engagement below.
Priced proposals built from the opportunity or CPQ quote, with the pricing table, terms and optional items assembled from the record instead of from last quarter's deck.
MSAs, order forms and statements of work with legal-approved clause blocks selected by conditional logic, so commercial teams cannot quietly ship unapproved terms.
Renewal paperwork and change orders generated from the existing contract record with the delta pre-filled, which is how a renewal becomes a signature rather than a negotiation.
A single send containing the agreement, data forms, billing setup and policy acknowledgements, so a new customer signs once instead of chasing four documents across three weeks.
Regulated intake documents with verified signer identity and a retained audit trail, filed against the customer record — the pattern we built into a real-estate compliance module.
Engagement letters, scoping documents and fee schedules generated from the client and matter records, with partner approval enforced before anything reaches the client.
Offer letters, vendor forms, commission statements and approvals — the internal paperwork that quietly consumes operations time and never makes it onto a project plan.
Six changes we would expect a well-designed implementation to produce. The size of each one depends on your volume and your starting point — which is what an assessment establishes, and what we will not guess at on a web page.
Generation stops being a task somebody schedules around. In our real-estate engagement, contract turnaround moved from two to three days down to hours once generation and signature ran from Salesforce.
When every value is merged from the CRM, the entire category of transcription error disappears — wrong entity names, stale addresses, totals that do not match the quote that was approved.
One governed template set with conditional clauses replaces a drive full of variants, so the language a customer receives is the language that was signed off — and changing it is a controlled action.
Sent, viewed, signed and stalled are fields on the record, so pipeline reviews use evidence. Leadership can see where documents sit rather than asking a manager to find out.
Approval history, signer identity and the certificate trail attach to the document and the customer record, which turns an audit request from a fortnight of searching into a query.
New reps inherit a workflow rather than a folder of examples, and a new product line is a template change instead of a retraining programme. Volume stops adding coordination cost.
Two engagements where documents were the bottleneck. Each figure below is scoped to the engagement it came from — the first ran on Salesforce, the second on HubSpot — and both are linked so you can read the full story rather than take the number on trust.
Twopir Consulting transformed our real estate operations by unifying AML/KYC, inquiries, contracts, and commission tracking into a single Salesforce–Propertybase platform. Their API-driven approach automated workflows, reduced errors, and enabled real-time data synchronization. With improved visibility, collaboration, and compliance, we now operate faster, smarter, and with greater confidence.
Nintex and PandaDoc wired into Salesforce opportunities, so contracts, offer letters and KYC onboarding forms generate from CRM data and return signed.
As a satellite broadband provider expanding across the Asia-Pacific, we needed a CRM system that could support both scale and precision. Twopir Consulting delivered a fully customized Salesforce Sales Cloud solution that streamlined our lead, account, and opportunity workflows. Their team also integrated Mailchimp and Box, enabling us to manage email campaigns and sales documents seamlessly.
Reps were spending 6–8 hours a week assembling proposals and chasing signatures. These figures are scoped to this HubSpot-side engagement, not to PandaDoc implementations in general.
PandaDoc implementations fail on the Salesforce side far more often than on the PandaDoc side — missing fields, an object model that cannot express the agreement, approvals nobody owns. That is the half we are strongest on.
Not a document vendor's reseller. When a merge field has no reliable source, or a contract needs a relationship the object model does not have, the fix is Salesforce work — and that is our home ground.
Every requirement is classified during assessment as configuration or custom development, with the cost consequence attached. You decide what to fund knowing which side of the line it sits on.
Real-estate transactions with AML and KYC obligations, professional-services engagement letters, multi-entity contracting. The edge cases — signer identity, retention, approval evidence — are already known to us.
We deliver PandaDoc, Nintex DocGen and Conga. That means we can tell you when PandaDoc is the right answer for a workflow and when it is not — advice a single-product partner has no commercial reason to give.
Pricing changes, legal rewrites a clause, a new product line arrives. Document systems drift faster than almost anything else in a CRM, so ownership after launch is part of the engagement rather than an upsell.
The parent practice: implementation, rescue, integration and optimization across the Salesforce platform.
Explore Salesforce servicesWhat PandaDoc does across the document lifecycle, for readers still deciding whether it belongs in their stack.
Read the PandaDoc overviewA practical walkthrough of templates, tokens and document structure for the admins who will maintain them.
Read the documents guideThe same document architecture on the HubSpot side, including the engagement behind the figures in our proof section.
Read the HubSpot guideThe sibling document-generation practice — useful if you are comparing the two, or already run both.
Compare Nintex DocGenHow seven automation modules, including PandaDoc document workflows, were delivered across three phases for a 250-agent brokerage.
Read the case studyWhere engagement letters, scoping documents and fee schedules sit inside a wider services operating model.
See the industry pageThe retained model that keeps templates, approval rules and integrations working after the project closes.
See support optionsSix things: installing and permissioning the managed package, checking that your Salesforce data can supply every value a document needs, rebuilding your live documents as governed templates, mapping tokens to CRM fields, automating generation, approval and status write-back, then testing and training before a staged go-live. The platform setup is the fastest part. Template design and data readiness are where the effort actually sits, and they are the two things that decide whether the result is trusted. We work on both new deployments and existing PandaDoc accounts that are not delivering.
It depends on three things: how many document types are in scope, how clean the Salesforce data behind them is, and whether legal has to review the template language. A focused first deployment — one or two document types on a healthy org — is a short engagement measured in weeks. A multi-entity, CPQ-driven rollout with legal review, custom development and migration from an existing tool runs considerably longer. We give a range at the end of assessment, once we have seen the org, rather than quoting a duration before we know which of those three factors is the hard one.
Configuration is everything PandaDoc and Salesforce can be set to do declaratively: templates, tokens, conditional content, approval rules, recipient roles, component placement and standard field mapping. Custom development begins the moment a requirement needs code, an API call, or an object the package does not natively handle — generating a document from an Apex trigger, assembling a package across several related records, embedding signing in a customer portal, or pushing status into a system outside Salesforce. We classify every requirement as one or the other during assessment, with the cost consequence attached, so nothing is discovered mid-build.
It depends on what the document has to do after it is generated. PandaDoc is strongest where the document is customer-facing and the signature is the point — proposals, quotes, contracts and onboarding packs that need an interactive experience, approval routing and eSignature in one product. Nintex DocGen and Conga are typically the better fit for high-volume internal or batch generation driven from Salesforce data, especially where output format and templating control matter more than the signing journey. Plenty of organizations run both. We deliver all three, so the recommendation is not a function of what we happen to sell.
Through a separate PandaDoc CPQ package, which requires Salesforce CPQ to already be installed in the org. Once configured, CPQ quote lines populate a PandaDoc pricing table, variables carry the values through, and the document value follows the quote's net amount. Quote sections control what flows back: where a section is set not to sync with its linked CRM object, its products are not exported to Salesforce. That behaviour is useful and also a common surprise, so we design it deliberately rather than discovering it in production. Sequencing matters here — installing in the wrong order is one of the more avoidable ways a go-live slips.
PandaDoc states that its electronic signatures are legally binding and compliant with the major electronic signature frameworks, including the ESIGN Act and UETA in the United States and eIDAS in the European Union, and that qualified electronic signatures are available where eIDAS requires that higher level. Each completed document carries a certificate and an audit trail recording the signers, verified email addresses, IP address and location, and the timestamps for when the document was sent, viewed and completed. Signer authentication options and third-party identity verification are available for documents that need stronger assurance. We configure which document types get which level of assurance with your legal team — it is a policy decision, not a default. For anything jurisdiction-specific, confirm the position with your own counsel and against PandaDoc's current documentation.
Yes, and we recommend it for document systems specifically. Templates drift faster than almost anything else in a CRM: pricing moves, legal rewrites a clause, a new product line arrives, a region gets its own terms. Our support model covers template changes and new document types, approval-rule tuning, monitoring where documents still stall, and enhancements as the business changes. Where a client prefers to own it internally, we hand over a documented build and train the admin team to run it — but somebody has to own it, and that should be decided before go-live rather than three months after.
A PandaDoc assessment looks at your document types, the Salesforce data behind them and the approvals around them, then comes back with a scope, a configure-versus-build split and an honest range. No obligation to build it with us.
Salesforce architects who implement PandaDoc — not a reseller
