Documents are still assembled by hand
Someone opens last quarter's agreement, saves a copy, and edits the names and numbers. It works until volume rises, and every copy is a chance to ship the wrong clause or the wrong figure.
FormAssembly · Consulting & Implementation
FormAssembly consulting and implementation, scoped before it is sold
Most of a FormAssembly project is Salesforce work: which object each field lands on, how documents get generated and signed, and what happens when a write fails. Twopir Consulting plans, configures, integrates, customises and supports FormAssembly — and tells you which parts are configuration and which parts are a build before anyone quotes. Assess, architect, build, hand over.
12+
500+
250+
15+
Trusted by 500+ organizations — including healthcare, legal and professional-services teams whose regulated intake runs into Salesforce with Twopir Consulting.
Built for Document & Data Operations
- Salesforce Partner
- HubSpot Partner
- FormAssembly Implementation
- Document Generation
- E-Signature Workflows
- Connector Architecture
- Compliance & Governance
- Managed Support
Where document and data operations quietly cost you
These are the problems organizations describe when they start evaluating FormAssembly consulting. Almost none of them are solved by building a better form — they are solved by deciding where data is captured, how documents are produced from it, and who has to touch it in between. The manual step is where the cost sits.
The same data is keyed in more than once
A client supplies details on a form, someone retypes them into Salesforce, and someone else retypes them into the document. Each hop is a place where the three versions stop agreeing.
Proposals and contracts take days to leave the building
The delay is rarely the writing. It is waiting for the right template, the right approval and the right signature, with no single place showing which of the three is holding things up.
Every team has its own version of the template
Regional variants multiply, nobody knows which one is current, and a change to standard terms means finding and editing an unknown number of files held in an unknown number of folders.
Approvals happen in email and leave no trail
A document is approved in a reply nobody can find later. When an auditor or a client asks who signed off and when, the answer takes an afternoon of searching instead of a click.
The process will not survive the next doubling
What one coordinator absorbs at fifty documents a month becomes three hires at five hundred. Manual document operations scale by adding people, which is the most expensive way to scale anything.
What This Service Is
What FormAssembly consulting and implementation actually covers
FormAssembly consulting and implementation services are the work of designing, configuring and integrating FormAssembly so that data collected from customers, staff or applicants lands correctly in your systems and drives the documents and approvals that follow. A typical engagement covers requirements discovery, solution architecture, FormAssembly configuration, document and template design, Salesforce integration, workflow automation, custom development where standard configuration cannot reach, testing, user training, deployment and ongoing support.
It is worth being precise about who does what. FormAssembly is the platform: it builds the forms, runs the connectors that read from and write to Salesforce, generates documents from templates, routes them for approval and signature, and files the result. FormAssembly, Inc. makes and licenses that product. Twopir Consulting is the delivery team: we decide how your object model, templates, permissions and downstream automation should be arranged, configure the platform to match, build what configuration cannot express, and hand the result to an internal owner. What you get is a documented, maintainable data-collection and document layer — not a licence and a folder of forms.
We work with growing, mid-market, and enterprise organizations that need help with complex CRM implementations, integrations, and business system challenges. Most of our FormAssembly work sits inside a wider Salesforce engagement, which is why our Salesforce consulting practice and this service share the same architects. If you want the platform explained before the service — what the connector does, where it fits, and whether it is the right tool at all — start with our FormAssembly and Salesforce integration guide.
Six workstreams that make up a FormAssembly engagement
Most engagements need three or four of these, not all six. The assessment decides which — before anything is quoted. Each workstream has a page of its own if you want the detail behind it.
Discovery & Solution Architecture
Before configuration, the decisions that constrain it: which processes move onto FormAssembly, which Salesforce objects receive the data, and where the compliance boundary sits.
- Current-state assessment of forms and manual steps
- Requirements capture with business and technical owners
- Salesforce object, record-type and relationship review
- Target architecture and integration design
- Edition, licence and permission-model guidance
FormAssembly Implementation & Configuration
Standing the platform up from nothing, or correcting an instance that was stood up in a hurry: forms, logic, connectors, permissions and the first production processes.
- Instance, user and permission configuration
- Form design, conditional logic and validation rules
- Connector build and field-level mapping
- Migration from legacy or general-purpose form tools
- Phased rollout and cutover planning
Document Generation & E-Signature
Turning a submission into the finished document it should produce — merged from a template, routed for approval, signed, and filed back against the record it belongs to.
- Template design with merge fields and conditional sections
- Document generation configured inside the workflow
- Approval routing and multi-signer e-signature steps
- Delivery by email and filing to Salesforce or storage
- Template governance so one change updates every output
Salesforce Integration
The half of the project that decides whether any of it works: prefill from existing records, writes across parent and child objects, duplicate handling, and what happens on every failure path.
- Prefill and authenticated, per-record form links
- Multi-object create, update and upsert design
- Lookup resolution and duplicate-matching strategy
- Dynamic picklists sourced from live Salesforce values
- Error paths, retries and failure alerting
Customization & Custom Development
For requirements the standard configuration cannot express. We build it in the layer that will still be maintainable in two years — usually Salesforce, not the form.
- Apex, Flow and trigger logic behind the write
- Complex conditional, calculation and pricing logic
- API and middleware work for systems with no connector
- Custom objects and audit-trail structures
- Bespoke form behaviour and branded experiences
Compliance, Support & Optimization
Making the collection defensible, then keeping it correct as objects, rules and teams change around it. This is where most inherited instances need attention first.
- Access, role and retention policy configuration
- Consent capture and audit-trail design
- Submission failure monitoring and alerting
- Admin enablement so your team owns day-to-day change
- Retained support and periodic optimization reviews
What FormAssembly does, and what we do with it
The left column is the product. The right column is the consulting work — the decisions that determine whether the product produces a clean record or a confident mess. Confirm the features available on your edition with the vendor before designing around them.
| Capability | What the platform does | What we configure or build |
|---|---|---|
| Salesforce Connector | Creates and updates records across related standard and custom objects from a single submission, resolving the lookups between them. | The write order, the record-type logic, the duplicate-matching strategy, and what the connector does when a match returns none, one or many. |
| Prefill | Reads existing Salesforce data when the form opens so a known submitter confirms details instead of retyping them. | Secure per-record links, which fields are safe to expose, and update-in-place behaviour so a correction changes the source record rather than creating a second one. |
| Document Generation | Merges submitted data into a template and produces a finished document, with conditional sections and repeating content. | Template structure and merge-field mapping, the conditional rules that decide which clauses appear, and template governance so one edit updates every output. |
| E-Signature | Routes a generated document for signature inside the same workflow, including multiple signers in a defined order. | Signer routing and order, what the signed state means downstream, and where the executed copy is filed so the record is complete without a second system. |
| Approvals | Sends a response to a named reviewer and continues down an approved or denied path based on the decision. | Who approves what at which threshold, escalation when a reviewer does not respond, and how approval status becomes visible on the Salesforce record. |
| Workflow & Conditional Steps | Chains multiple forms, connectors, documents and approvals into one tracked process that branches on submitted data. | The process map itself: where it branches, what each participant sees, how a long submission is resumed, and how anyone can tell where a case currently sits. |
| Compliance & Access Controls | Supports regulated collection with role-based access, audit logs, SSO and administrative data controls. | Your actual policy: who may view a submission, how long it is kept, what the audit trail has to show, and evidence that survives an external question. |
| API & Custom Integration | Exposes APIs and connectors for systems beyond the native integration list. | Middleware for the platforms with no native connector, authentication and retry handling, and the monitoring that tells you when an integration stops. |
From requirements discovery to a system your team owns
Six phases, one continuous engagement. A single well-scoped process on a clean object model moves quickly; a regulated multi-step workflow writing across a complicated org does not. The assessment is what tells us which one you have before either side commits to a date.
Business & Requirements Discovery
We work through the process with the people who run it — what is collected, who reviews it, what document it produces, who signs. Requirements gathered only from a systems owner tend to miss the manual steps the business has quietly normalised, and those are usually the expensive ones.
Current-State Assessment
If you already run FormAssembly, we trace real submissions through the existing connectors and find where records fail to land, duplicate or go unattached. If you do not, we assess the Salesforce side instead: relationships, record types, validation rules and duplicate strategy. This phase is what makes the estimate real rather than optimistic.
Solution Architecture & Design
We write the design down before anything is built: which field lands on which object in what order, which templates produce which documents, where approvals sit, who may see what, and what happens on every failure path. This is also where we separate configuration from custom development, so you can see which is which before you approve a budget.
Configuration, Templates & Integration
The build itself: FormAssembly instance and permission setup, forms and conditional logic, document templates and merge mapping, connector configuration and prefill, approval and signature routing, plus any Apex, Flow or middleware the design calls for. Customization is scoped as its own line, never folded into configuration hours.
Testing, Validation & Training
We submit real scenarios end to end and confirm every record lands, every document merges correctly, and every failure raises an alert — including the paths nobody wants to test, like a rejected approval or a write that hits a validation rule. Training runs against the built system, with your admin doing the clicking rather than watching.
Deployment, Support & Optimization
We release by process or team rather than switching everything at once, monitor submission failures through the first cycles, and hand over documentation your admin can actually work from. Afterwards the mapping has to stay correct as objects, validation rules and teams change around it — which is what retained support is for.
Four ways organizations buy this work
Knowing which of these you need is most of the scoping conversation. They are usually bought by different people, for different reasons, at different points in the platform's life with you.
| Engagement | You are here if… | What it covers | What you are left with |
|---|---|---|---|
| Assessment | You are evaluating FormAssembly, or you own it and cannot explain why submissions behave the way they do. | Process and object-model review, connector trace against live submissions, findings split into configuration and build. | A written scope and a defensible estimate — including the honest answer if you do not need the platform. |
| Implementation | You have bought FormAssembly and nothing is live yet. | Instance and permission setup, first production forms and connectors, document and signature workflows, migration, UAT, training and phased rollout. | A running system, documented mapping, and an internal admin who can operate it. |
| Optimization | It is live, but submissions do not land right, or the process has outgrown how it was first configured. | Connector and mapping correction, duplicate and error-path handling, workflow redesign, template consolidation, failure alerting. | Corrected behaviour without rebuilding forms that already work. |
| Retained Support | The build is done and the org keeps changing around it. | Change requests, new forms and templates, monitoring, admin escalation, and periodic optimization reviews. | A mapping that stays correct as objects, rules and teams change. |
Where the boundary sits
If the behaviour can be expressed with the connector's own mapping, lookups, conditional logic and formulas, it is configuration and it belongs in the platform — we will tell you so rather than bill for it. It becomes custom development when the write depends on logic the connector has no field for, on data it cannot reach at submission time, or on a system it does not integrate with natively. Most engagements are mostly configuration with a small, well-defined build around the edges, and we scope those separately so you can see which is which.
The decisions that outlive the build
Eight questions we answer in design rather than discover in production. A technical evaluator can reasonably ask any partner to show their position on each of these before signing anything.
Salesforce data architecture
Which objects receive the submission and how they relate. A connector faithfully produces the wrong records when the relationships underneath it were never modelled properly.
Write order and dependencies
Parent records have to exist before the children that reference them. Getting the order wrong is the most common cause of a submission that half-lands and leaves someone to finish by hand.
Duplicate strategy
What counts as the same person, and what the platform should do on none, one or several matches. Left undecided, every submission creates a new contact and the CRM degrades quietly.
Security and access model
Who can open a form, who can read a submission, and whether a link alone is sufficient credential for the data it carries. Regulated collection usually means authenticated access, not just an unguessable URL.
Where the automation lives
Logic placed in the form applies only to data arriving through that form. Logic placed in Salesforce applies to every route data arrives by — which is usually where it belongs.
Template and document governance
One managed template with conditional sections beats nine regional copies. The test is simple: when standard terms change, how many files does someone have to open?
Failure handling and alerting
What the submitter sees, what the owner is told, and whether the data survives long enough to be recovered. A silent failure is a complaint you receive weeks later.
Scalability and maintainability
Whether adding the eleventh process costs what the second one did. That depends on how much was made reusable in design, not on how quickly the first one shipped.
What teams actually run on it
Six processes we are asked for repeatedly. The pattern is the same each time: capture once, write to the record, generate the document, route it for a decision, file the result.
Real estate transaction documents
Listing agreements, disclosures and buyer representation forms generated from the property and contact record, signed in the flow, and filed back against the transaction.
Proposals, quotes and contracts
Pricing and scope captured once, merged into a branded document with the right optional clauses, approved by whoever the value threshold requires, then sent for signature.
Client and customer onboarding
A prefilled onboarding pack where the client confirms what you already hold rather than retyping it, with the corrections updating the source record instead of creating a second one.
Regulated intake and consent capture
Patient, student, applicant or claimant data collected with the access, retention and consent posture the obligation requires — and an audit trail that answers a question without an investigation.
Renewals and recurring paperwork
Annual re-enrolments, re-certifications and renewal agreements issued from the existing record, so the recurring cycle stops being a recurring data-entry project.
Internal request and approval workflows
Purchase requests, change forms and access approvals routed by value or department, with the decision, the approver and the timestamp all recorded where an auditor can find them.
What changes once the manual step is gone
Six things that become true when collection, generation and approval run as one designed process. Ask any partner to show you these in your own submissions before and after — the improvement should be visible in your data, not only in a slide.
Documents are produced, not assembled
The agreement is generated from the record that already holds the facts. Nobody opens last quarter's version, and nobody ships the wrong figure because they edited the wrong copy.
Data is entered once and only once
What the submitter types lands in Salesforce and flows into the document from there. The three versions of a client's address collapse back into one.
Turnaround stops depending on who is available
Generation and routing happen on submission rather than when a coordinator gets to it, so the elapsed time between request and signature is a process property instead of a staffing one.
Output is consistent across teams and regions
One managed template with conditional sections replaces the folder of variants, so a change to standard terms is one edit rather than an audit of everything anyone ever saved.
Approvals leave a trail
Who approved what, when, and on which version becomes a record rather than a search through an inbox — which is the difference between answering an audit and preparing for one.
Volume stops costing headcount
Doubling the number of documents stops implying another coordinator. That is usually where the business case for the licence and the engagement actually lands.
The same pattern, on neighbouring systems
Two published engagements where the work was the same shape as a FormAssembly project — capture data once, write it correctly across objects, and remove the manual step in between. Neither was a FormAssembly build, and the figures belong to those engagements, not to this platform.
★★★★★
Twopir streamlined administration and billing, leading to seamless financial operations and enhanced productivity. Automated mass billing and matter management minimized errors across our entire workflow.
David K. COO, Regional Group Practice Healthcare Group
Multi-Site Specialty Clinic — Patient Operations
Intake, referral and administration workflows rebuilt on Salesforce.
3× Faster patient inquiry response
58% Drop in admin time on intake
42% Better referral-to-appointment rate
Also relevant: how we rebuilt case-to-cash operations for a multi-state law firm across Salesforce, document processing and financial systems.
Not a form shop. An architecture partner.
Most FormAssembly projects do not fail in the form builder. They fail in Salesforce, in the template library, or in the handover — which is where we are set up to work.
We scope configuration and custom build separately
You are told which parts are mapping and which parts are development, and priced accordingly. If something is already possible in the connector, we say so instead of quoting for it.
We work on both sides of the connector
We hold Salesforce Partner and HubSpot Partner status and have our own development capability, so the Salesforce half of the problem does not get handed to a second vendor with a different timeline.
We start at the object model, not the form
Relationships, record types, duplicate rules and validation decide whether any mapping can be correct. Fixing that first is why our builds tend to survive the next change to the org.
We design the failure paths, not just the happy path
Most inherited setups work perfectly until a write fails, then lose the submission silently. What happens on the error path is part of the design here, not an afterthought.
We build what your team can maintain
The mapping is documented and explainable. Your admin should be able to add a field without calling us, and should be able to tell what a form does by reading it.
Go deeper on a specific workstream
This page covers how a FormAssembly engagement is scoped and delivered. Each of these covers one part of it in detail.
Platform Guide
FormAssembly and Salesforce integration
What the platform does, who it suits, and where configuration ends and custom development begins.
ImplementationFormAssembly implementation services
Plan selection, instance and permission setup, first production forms, legacy migration and handover.
ConnectorFormAssembly Salesforce connector work
Prefill, lookups, deduplication, dynamic picklists, conditional writes and error handling.
WorkflowFormAssembly workflow automation
Multi-step processes, approvals, e-signature routing and document generation inside one tracked flow.
CustomizationFormAssembly customization services
The build work for requirements the standard connector configuration cannot express.
APIsFormAssembly API and custom integrations
Middleware and API work for the systems with no native connector on either side.
ComplianceFormAssembly security and compliance consulting
Access, retention, consent capture and the audit trail behind regulated data collection.
ComparisonFormAssembly compared with other form builders
How FormAssembly, Formstack, FormTitan and 123FormBuilder differ where it matters.
Parent ServiceSalesforce consulting and implementation
The wider practice this work sits inside, from CRM architecture to integration and support.
Comparing document tooling rather than form tooling? See our Formstack Documents implementation, Conga Composer implementation, Nintex document automation and DocuSign Gen for Salesforce services.
Answers before the first call
A full engagement covers requirements discovery, current-state assessment, solution architecture, FormAssembly configuration, document and template design, Salesforce integration, workflow and approval automation, custom development where needed, testing, user training, deployment and post-implementation support. Most clients do not buy all of it at once — the assessment decides which workstreams the process actually needs, and the rest stays out of scope until it is justified.
It depends far more on your Salesforce org than on the number of forms. A single well-scoped process writing to a clean object model moves quickly. A regulated multi-step workflow that generates documents, collects signatures and writes across several related objects in a heavily customised org does not. What drives the timeline is the number of objects touched, whether a duplicate strategy already exists, how many templates need consolidating, and how much of the logic has to move into Salesforce. We give a date after the assessment, not before it.
We quote after the assessment, and we quote configuration and custom development as separate lines so you can see which is which. Any partner giving you a number before looking at your object model is pricing a guess. The cost drivers are consistent: how many Salesforce objects a submission has to touch, whether the relationships and duplicate rules are already sound, how many document templates exist and how many of them should, and whether any of the logic needs to be built rather than configured. Your FormAssembly licence is separate and bought directly from the vendor.
Yes, and it is where a large share of our engagements start. The cause is usually the mapping rather than the forms. Typical findings are a write order that does not respect record relationships, lookups that fail quietly and leave records unattached, no duplicate strategy so every submission creates a new contact, and no alerting on failures so nobody knew. We trace real submissions through the connector, correct the mapping, and rebuild only the parts that are misfiring. Rebuilding the forms is rarely necessary.
FormAssembly generates documents from a template populated with the data in a workflow, applies conditional sections, routes the result for approval and signature, and files it back to Salesforce or a storage system. When a Salesforce record can prefill the form, that record's data reaches the document too. Where a separate document tool still earns its place is generation driven entirely from Salesforce with no form in the process, or very complex contract lifecycle requirements — which is why we also implement Conga Composer, Formstack Documents and Nintex. If a form starts the process, FormAssembly usually does the whole job. Confirm which document features your edition includes with the vendor.
We implement FormAssembly; we do not resell it. You buy your licences from FormAssembly directly. Our credentials are Salesforce Partner and HubSpot Partner, which is the side of this problem most of the work sits on. The practical benefit of that split is that we have no incentive to put you on a larger edition than your data model needs.
Less than most people expect, but it has to be the right people. We need a business owner who can decide how the process should work, a Salesforce admin with access to the org, and whoever owns the document templates and the approval policy. The heaviest demand is during discovery and user acceptance testing. We also ask for a named internal admin from the start, because they are trained during the build rather than handed documentation at the end — that is the difference between owning the system afterwards and depending on us for every field change.
Next Step
Start with an assessment, not a quote
We trace your real process, show you where records fail to land or documents get rebuilt by hand, and tell you plainly which parts are configuration and which parts are a build — before anyone talks about scope.
Speak with a team that works on both sides of the connector
