The form writes to one object, the data belongs in five
A submission that should create a contact, an account, a case and two child records lands as one row. Someone finishes the job by hand, and the handoff is where errors enter.
Salesforce · Data Collection
Building the form is the easy part. Landing the data correctly is the work.
FormAssembly earns its licence on the Salesforce Connector, not the form builder: prefilling from records you already hold, then writing one submission across several objects with the right lookups, upserts and error handling. Twopir Consulting implements FormAssembly, configures that connector against your real object model, and builds the custom work standard configuration cannot reach. Prefill, collect, validate, write back.
12+
500+
250+
15+
Trusted by 500+ organizations — teams collecting regulated and business-critical data straight into Salesforce with Twopir Consulting.
.png){kind=small}
-3.png){kind=small}
Built for Regulated Data Collection
- Salesforce Partner
- HubSpot Partner
- FormAssembly Implementation
- Salesforce Connector Architecture
- Prefill & Authenticated Forms
- Compliance & Data Governance
- Custom Development
- Managed Support
Where data collection breaks down
Almost none of these are form-building problems. They are data-model, compliance and integration problems that only become visible at the moment someone hits submit. The form is where the symptom shows, not where the fault is.
People retype data you already hold
Without prefill, a known client re-enters their own details. It reads as careless to them, it drives drop-off, and every retyped field is a fresh chance to create a duplicate.
Regulated data is collected in a tool that cannot hold it
Health information, payment details or student records arriving through a general-purpose form builder is a compliance exposure long before it is a data problem.
Validation happens after the record is already created
Bad addresses, malformed IDs and impossible dates get cleaned in the CRM weeks later, by someone who was not there when the data was entered and has to guess at intent.
A multi-step process is split across disconnected forms
Application, review, approval and signature each live in their own form with their own copy of the data. Nobody can answer where a given submission currently sits.
Failed submissions disappear silently
A write fails on a validation rule or a missing lookup and nobody is told. The submitter believes they are done, the record never exists, and it surfaces as a complaint.
What It Is
What FormAssembly is, and who it's actually for
FormAssembly is an enterprise data-collection platform whose defining capability is its Salesforce Connector. It can prefill a form from records that already exist in Salesforce, and it can write a single submission across several Salesforce objects in one pass — creating and updating related records, resolving lookups, and handling the errors when a write fails. It is made by FormAssembly, Inc.
The second reason organisations choose it is where the data is allowed to live. FormAssembly is positioned for regulated collection — the kind of health, financial, student and personal data that a general-purpose form builder should never be holding. Confirm the specific certifications and hosting options that apply to your obligations directly with the vendor before you design around them, because the answer depends on your edition and region.
What the product does not do is design your data model. The connector executes the mapping it is given; whether that mapping is correct depends on your object relationships, record types, validation rules and duplicate strategy inside Salesforce. That is the layer Twopir works on. We treat FormAssembly as one component of a data architecture rather than the architecture itself — which is why our engagements start with the objects, not the form.
Implement, configure, or build on top of it
Three separate pieces of work, usually bought by three different people. Knowing which one you need is most of the scoping conversation.
Implement
A first deployment. We map your objects, stand up the connector, set the compliance and access posture, and get real submissions landing correctly before anyone depends on them.
- Data model and object mapping review
- Salesforce Connector build and field mapping
- Compliance, access and retention configuration
- Form, logic and notification setup
- UAT, phased rollout and team enablement
Configure
You already own it and submissions are not landing right. We trace real failures through the connector, correct the mapping, and rebuild the logic that is misfiring — usually without rebuilding the forms.
- Connector audit against live submission data
- Multi-object write and upsert correction
- Prefill and authenticated-form setup
- Validation, duplicate and error-path handling
- Workflow, notification and response cleanup
Build on
The requirement has outrun the connector. We build the custom logic, objects and integrations around the product so it serves a process the standard configuration cannot express.
- Custom Apex, Flow and trigger logic in Salesforce
- API and middleware work for non-native systems
- Complex conditional and calculation logic
- Document generation and downstream automation
- Custom reporting objects and audit trails
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 — and often the right answer is to move that logic into Salesforce rather than the form. Most engagements are mostly configuration with a small, well-defined build around the edges, and we scope those two separately so you can see which is which.
What we actually build on FormAssembly
Six workstreams. Most engagements need three or four of them — the audit decides which, before anything is quoted.
Salesforce Connector Architecture
The core of the work: designing how one submission becomes the right set of related records, and what happens on every path where that write can fail.
- Multi-object create, update and upsert design
- Lookup resolution and record-type handling
- Duplicate strategy and matching rules
- Ordered writes across parent and child records
- Error paths, retries and failure notification
Prefill & Authenticated Forms
Stop asking people for data you already hold. Known submitters see their own record, correct it, and the correction updates the source instead of creating a second copy.
- Prefill from existing Salesforce records
- Secure, per-record form links
- SSO and authenticated access where required
- Update-in-place instead of duplicate creation
- Expiry, access control and link governance
Compliance & Data Governance
Making the collection defensible: who can see a submission, how long it is kept, where it is stored, and what the audit trail shows when someone asks.
- Access, permission and role configuration
- Retention and deletion policy implementation
- Consent capture and lawful-basis recording
- Audit trail and submission history
- Alignment with your obligations, confirmed with the vendor
Multi-Step Workflows & E-Signature
Processes that take more than one form and more than one person — application, review, approval, signature — held together as one tracked case rather than four disconnected steps.
- Multi-step and multi-party workflow design
- Save-and-resume for long submissions
- E-signature capture in the flow
- Review, approval and escalation routing
- Status visibility on the Salesforce record
Payments, Files & Documents
The attachments to a submission that usually get handled separately — a payment, an uploaded file, a generated PDF — brought into the same transaction and the same record.
- Payment collection tied to the submitted record
- File upload routing and storage
- Document generation from submitted data
- Receipt, confirmation and follow-up automation
- Reconciliation back to Salesforce
Migration, Support & Tuning
Moving off a form tool that cannot do this, and keeping the result correct afterwards as objects, rules and teams change around it.
- Migration from legacy and general-purpose form tools
- Historical submission data handling
- Submission failure monitoring and alerting
- Change support as the data model evolves
- Retained support for admins and operations teams
FormAssembly and Salesforce, as a round trip
The connector reads before it writes. Data comes out of Salesforce to prefill the form, and the completed submission goes back across several objects — which is what separates this from a form tool that simply posts a payload.
Salesforce
The system of record on both ends of the trip — the source for prefill and the destination for the write.
Payment Processing
Payment taken as part of the submission, so the transaction and the record it belongs to are created together.
E-Signature
Signature captured inside the flow rather than chased afterwards by email, with the signed state on the record.
File Storage
Uploaded documents routed to the right storage and linked to the record, not left sitting in the form tool.
SSO & Identity
Authenticated access where a form carries personal or regulated data, so a link alone is not the credential.
Email & Notifications
Confirmations to the submitter and alerts to the owner, including the failure alerts most setups never configure.
Reporting & BI
Submission and completion data modelled so volume, drop-off and failure rates are reportable, not anecdotal.
Custom APIs
Middleware for the systems with no native connector — a billing platform, an EHR, a student system, an internal service.
| Data | Direction | Why it matters |
|---|---|---|
| Existing contact, account and case fields | Salesforce → Form | The submitter confirms what you already hold instead of retyping it and creating a second version. |
| Picklist values and reference data | Salesforce → Form | Options stay in step with the org, so submissions cannot introduce values the field will reject. |
| Record identity behind a secure link | Salesforce → Form | The submission updates the right record rather than arriving unattached for someone to match by hand. |
| Submitted fields across parent and child objects | Form → Salesforce | One submission becomes the full set of related records in one pass, with no manual completion step. |
| Uploaded files and generated documents | Form → Salesforce | Attachments land on the record they belong to, so the case is complete without a second system. |
| Payment and signature status | Form → Salesforce | Paid and signed are states on the record, which is what lets downstream automation act on them. |
| Write failures and validation errors | Form → Owner | A failed submission raises an alert instead of vanishing, which is the difference between a fix and a complaint. |
From data audit to a system that holds
Five stages. A single well-scoped form on a clean object model moves quickly; a regulated multi-step process writing across a complicated org does not, and the audit is what tells us which one you have before either side commits to a date.
Data & Compliance Audit
We trace what you collect, where it has to land, who may see it and how long it may be kept — and test whether your object model can support the writes you want.
Form & Object Mapping
We write the mapping down before anything is built: which field lands on which object, in what order, and what happens on every failure path.
Build & Connect
We build the forms, configure the connector, wire prefill and validation, and add any custom Salesforce logic the mapping needs behind it.
Test & Roll Out
We submit real scenarios end to end, confirm every record lands and every failure alerts, then release by form or team rather than switching everything at once.
Support & Tune
We monitor submission failures through the first cycles and keep the mapping correct as objects, validation rules and teams change around it.
What correct data collection changes
Six things that are true once the collection layer is built against the data model rather than bolted beside it. Ask any partner to show you these in your own submissions before and after.
One submission produces every record it should
The contact, the related case and the child records all exist when the submitter finishes, with nobody finishing the job by hand afterwards.
Bad data is refused at the point of entry
Validation happens while the person who knows the answer is still on the page, instead of becoming a cleanup task for someone who has to guess at intent.
Known people stop retyping what you hold
Prefill turns a form into a confirmation. Completion goes up because there is less to do, and duplicates go down because there is less to re-enter.
You can answer where regulated data lives
Access, retention and audit trail are decisions someone made deliberately, so a compliance question has an answer rather than an investigation.
Multi-step processes stay one process
Application, review, approval and signature move as a single tracked item, so anyone can say where a submission currently sits.
Failed submissions surface immediately
A write that fails raises an alert with the reason attached, which turns a silent data loss into a fix someone makes the same day.
Related delivery work: form-to-Salesforce automation and document generation from Salesforce data. Neither is a FormAssembly engagement — they are the collection, mapping and write-back work this page describes, on the same platform.
Who this is built for
Four teams buy this work, for four different reasons — and one situation where we will tell you not to buy it at all.
Regulated Operations
You collect health, financial or personal data and need the collection layer to be defensible, not just functional. See also Salesforce for healthcare.
Nonprofit & Education
Applications, registrations and donations arriving at volume, all needing to land on the right constituent record. See also Salesforce for nonprofits.
Revenue & Marketing Ops
You own the forms that feed pipeline and want submissions to arrive complete, attributed and ready to act on.
Salesforce Admins
You inherited a connector nobody documented and need it audited, explained and made maintainable.
When we will say no: if you need a handful of simple forms writing to a single object with no regulated data, a general-purpose form tool will do the job for a fraction of the licence. And if the object model itself is the problem — no duplicate strategy, unclear relationships, validation rules nobody can explain — no form tool will save you. In that case the honest first project is the data model, and that is a conversation about your CRM architecture, not about forms.
Not a form shop. An architecture partner.
Most FormAssembly projects fail in Salesforce, not in the form builder. That is the work we are set up to do.
We start at the object model, not the form
Relationships, record types, duplicate rules and validation decide whether any mapping can be correct. We fix that first, which is why our builds tend to survive the next change to the org.
We work on both sides of the connector
We are a Salesforce Gold Partner and HubSpot Gold Partner with our own development capability, so the Salesforce half of the problem does not get handed to a second vendor with a different timeline.
We separate configuration from custom development
You get told which parts are mapping and which parts are a build, and priced accordingly. If something is already possible in the connector, we say so instead of quoting for it.
We design the failure paths, not just the happy path
Most inherited setups work perfectly until a write fails, and then lose the submission silently. What happens on the error path is part of the design, 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.
Answers before the first call
Less form building than people expect, and more Salesforce work. Laying out fields is quick. The real work is deciding which object each field lands on, in what order the related records get written, how lookups resolve, what counts as a duplicate, and what happens when a write fails. A single well-scoped form on a clean object model moves quickly; a regulated multi-step process writing across a complicated org does not, and the audit tells us which one you have before either side commits to a date.
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. Often the right answer is to move that logic into Salesforce rather than the form, so it applies to every route data arrives by, not just this one.
Yes — that is the main reason to choose this platform over a general-purpose form tool. The connector can create and update records across related objects in one pass, resolving the lookups between them. Whether it works cleanly depends on your side: the relationships have to be modelled correctly, the write order has to respect them, and the duplicate strategy has to be decided rather than assumed. When those are wrong the connector faithfully produces the wrong records, which is what most of our audit work uncovers.
Regulated collection is one of the platform's main positioning points, and it is a common reason our clients move to it. What we will not do is tell you which certifications cover your obligations, because that depends on your edition, your region and your own regulatory position — confirm those directly with FormAssembly before designing around them. What we do is build the collection so it is defensible in practice: access and permissions, retention and deletion, consent capture, and an audit trail that answers a compliance question without an investigation.
That is where a large share of our engagements start, and the cause is usually the mapping rather than the forms. Typical findings are a write order that does not respect the 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.
If you need a handful of simple forms writing to a single object, with no regulated data and no prefill, a general-purpose form tool will do the job for a fraction of the licence and we will say so. The case for this platform is specific: writing across several related objects in one submission, prefilling from records you already hold, and collecting data that carries a regulatory obligation. If none of those three apply, you are paying for capability you are not using.
No. You buy your licences from FormAssembly directly, and we implement and integrate the product for you. We are a Salesforce Gold Partner and HubSpot Gold Partner, which is the side of this problem our credentials are on and where most of the work sits. The practical benefit of that split is that we have no incentive to put you on a larger edition than your data model needs.
Next Step
If your forms collect more than your records can hold, this is the right conversation
Start with the audit. We trace your real submissions, show you where records fail to land or duplicate, and tell you plainly which parts are mapping and which parts are a build — before anyone talks about scope.
Speak with a team that works on both sides of the connector
Delivering certified expertise to transform CRM, marketing automation, and AI-powered business processes for growing organisations worldwide.
🇮🇳
India Office
Building 4A, Ground Floor, SP Infocity SEZ,
Phursungi, Pune, Maharashtra – 412308
✉ info@twopirconsulting.com 📞 +91 74208 94628🇺🇸
USA Office
New Haven, Connecticut,
United States - 06513
✉ info@twopirconsulting.com 📞 +1 (888) 912-9340Salesforce
HubSpot
Industries
AI & Automation
Industry Apps
