Every submission creates a duplicate
Without lookup logic and a deduplication rule, a returning applicant becomes a second Contact. Three intakes later, sales, service and finance are each working a different copy of the same person.
Salesforce · Secure Data Collection
Your forms are a data pipeline. We architect them like one.
FormAssembly is where regulated data enters your business — applications, enrolments, claims, consents, payments. What happens next is an architecture question, not a form question. Twopir Consulting designs the connector logic, workflow routing and compliance configuration that turn submissions into clean Salesforce and HubSpot records. Collected once, validated at the edge, recorded correctly.
12+
500+
40+
250+
Trusted by 500+ organizations — including healthcare, higher education, nonprofit and financial services teams that collect regulated data every day.
Built for Regulated Data Collection
- Salesforce Partner
- HubSpot Partner
- Salesforce Connector
- HubSpot Connector
- Workflow Automation
- HIPAA & GDPR Configuration
- API & Webhooks
- Higher Education
Six ways form data quietly damages your CRM
A form that submits successfully can still be a liability. The damage shows up downstream — in duplicate records, failed connectors, stalled approvals and a compliance file nobody can reconstruct. The form is rarely the problem. The architecture behind it is.
Connectors fail silently after the thank-you page
When a connector runs in the After Form Submitted stage, the respondent is redirected whether or not it succeeded. The submission is safe in FormAssembly and missing from Salesforce — and nobody finds out until month-end.
Approvals live in email, not in the system
A form captures the request, then the decision happens in an inbox. There is no record of who approved what, no escalation when it stalls, and no way to report on cycle time.
Regulated data is collected on an unregulated plan
HIPAA support, a signed BAA, secure file scanning and the FedRAMP-authorized environment are not switches on every plan. Teams routinely collect protected health information on a tier that was never scoped to hold it.
The same data is re-keyed three times
A prospect types what you already know, staff retype it into the CRM, and finance retypes it again for billing. Prefill and connector mapping exist precisely to remove those steps, and are the two things most often left unconfigured.
Nobody can report on the process itself
You can count submissions. You cannot answer how many stalled at approval, where applicants abandon, or which channel produces the cleanest records — because the process was never modelled as data.
What It Actually Is
FormAssembly is a data collection platform that happens to build forms
FormAssembly is a web-based platform for collecting data through forms and multi-step workflows, and delivering that data into the systems where work actually happens. Its distinguishing capability is not the form builder — it is the connector layer: forms can read from and write to Salesforce, HubSpot, payment processors and custom endpoints, before, during and after a submission. FormAssembly states its own mission as helping organizations collect, use and be good stewards of the personal data entrusted to them, and the product is built accordingly, with compliance controls that most form tools treat as an add-on. The vendor's full technical documentation is the FormAssembly Resource Center.
Who it is for: organizations where the data being collected is sensitive, regulated or operationally critical — patient intake, student applications, donor and grant submissions, account opening and KYC, vendor onboarding, consent capture. If a submission triggers a process rather than just an email, FormAssembly is in the right category. If you need a contact form on a marketing site, it is not.
What Twopir does, and what the product does. FormAssembly provides the builder, the connectors, the workflow engine and the compliance certifications. Twopir Consulting designs how your organization uses them: the data model the forms write into, the lookup and deduplication rules, the approval routing, the error handling, the plan and permission configuration, and the integration architecture around it. We implement FormAssembly — we are not a FormAssembly reseller, and we do not claim a vendor partner tier we do not hold.
Implement it, configure it, or build on top of it
These are three different services with three different buyers, and confusing them is how projects get mis-scoped. Here is where each one starts and stops — and where the line between configuration and custom development actually sits.
Implement
You do not have FormAssembly yet, or you have it and nothing is connected. We stand the platform up end to end and hand over something your team can run.
- Plan and licence selection against your compliance profile
- Instance setup, user roles and permission model
- First production forms and connector configuration
- Migration from a legacy form tool, with parallel run
- Admin enablement and documented handover
Configure
You have FormAssembly and it works, but it does not do what the business needs. We change behaviour using the platform's own capabilities — no code deployed, nothing to maintain.
- Conditional logic, formulas and field validation
- Connector mapping, lookups and deduplication rules
- Workflow steps, approval paths and conditional routing
- Themes, branding, translations and accessibility
- Retention, masking and permission tightening
Build on
The requirement is past what configuration reaches. We build around the platform using its API and webhook surface, and we tell you plainly when that line has been crossed.
- Webhook integrations to homegrown and legacy systems
- REST API automation for provisioning and data export
- Middleware for transformation, retry and reconciliation
- Custom JavaScript where the form itself must do more
- Salesforce-side Apex, Flow and data-model work
| Requirement | Configuration reaches it | Needs custom development |
|---|---|---|
| Create or update a Salesforce record | Yes — the Salesforce connector maps form fields to any object, including related records. | Only when the write depends on logic Salesforce must run first. |
| Avoid creating duplicates | Yes — lookups plus the connector's multiple-records handling cover most matching rules. | When matching needs fuzzy logic or an external match service. |
| Calculate a value on the form | Yes — formulas cover Excel-style calculation in text fields. | When the calculation must run inside a connector, where formulas do not apply. |
| Route for approval | Yes — Workflow approval and conditional steps model most approval chains. | When approval state must be owned by another system of record. |
| Send data to a system with no connector | Yes — the Webhook connector posts authenticated JSON to any endpoint. | When the target needs transformation, retry logic or a reconciliation ledger. |
| Bulk-manage forms, users or responses | Partly — the admin UI covers routine cases. | At scale, through the REST API available on all plans. |
The work that makes FormAssembly behave like infrastructure
Six workstreams. Most engagements start with one and grow into three — the architecture decisions in each are connected, which is why we rarely recommend buying them separately.
Form & Data Model Design
We design the form around the record it has to create, not the other way round. That decision governs everything downstream.
- Field-to-object mapping designed before the form is built
- Conditional logic and branching that shortens completion
- Validation and formulas that reject bad data at the edge
- Repeatable sections for line items and multi-party records
- Datasets and autosuggest for long controlled lists
Connector Architecture
The connector layer is where most FormAssembly projects succeed or quietly fail. We treat it as integration work, because it is.
- Prefill from Salesforce, including related objects
- Lookup, matching and multiple-records handling
- Create and update across parent and child objects
- Conditional processing so records are written only when they should be
- Error handling, connector logs and response reprocessing
Workflow & Approval Design
Multi-step processes modelled in the platform instead of in email, so every decision is recorded and every delay is visible.
- Multi-form workflows with participant routing
- Approval steps with approved and denied paths
- Conditional rulesets that branch on submitted values
- Escalation and reminder design for stalled steps
- Workflow-native connectors at the right step
Security & Compliance Configuration
The certifications are the vendor's. Whether your configuration actually earns them is ours — and that is where audits are lost.
- Plan selection against HIPAA, GLBA, FERPA or FedRAMP need
- Respondent authentication with SAML, CAS or LDAP
- Field-level masking and sensitive-data handling
- Retention policies and secure file scanning
- Permission model, audit logging and access review
API & Custom Integration
When there is no connector for the system that matters, the webhook and REST surfaces are the supported way through.
- Webhook connector with OAuth or API-key authentication
- Custom JSON payloads, headers and conditional dispatch
- REST API automation for provisioning and export
- Middleware for transformation and guaranteed delivery
- Integration to homegrown and legacy line-of-business systems
Rescue & Ongoing Support
If you inherited an instance nobody documented, we start by finding out what it actually does before changing any of it.
- Audit of forms, connectors, workflows and permissions
- Repair of failing connectors and orphaned submissions
- Consolidation of duplicated and abandoned forms
- Documentation of what exists and why
- Retained support as volume and requirements grow
What moves between FormAssembly and the rest of your stack
Connectors run at three points in a submission's life — when the form opens, when it is submitted, and after the respondent has been redirected. Which stage a connector runs in changes what the respondent sees when something fails, so it is an architecture decision, not a checkbox.
FormAssembly + Salesforce
So staff stop re-keying and records stop duplicating. On open, the form reads Contact, Account and related records to prefill; on submit, it writes back to any standard or custom object. Errors surface in the connector log, where a failed response can be corrected and reprocessed.
FormAssembly + HubSpot
So marketing keeps its automation while the form keeps its compliance controls. The HubSpot connector, launched in 2025, creates and updates contacts and associated records from a submission — and one submission can be split, sending marketing data to HubSpot and sensitive data elsewhere.
FormAssembly + Payments
So the payment and the record it belongs to are created together. Stripe, PayPal, Authorize.Net and Deluxe connectors collect one-time and recurring payments at submission; the resulting transaction reference lands on the CRM record, so finance and service see the same truth.
FormAssembly + Marketing Cloud
So campaign journeys start from verified data. Forms can prefill from and write to Salesforce Marketing Cloud records, and Account Engagement is reachable through the webhook connector where a native path does not exist.
FormAssembly + Your Own Systems
So a homegrown system is not a reason to keep a paper process. The webhook connector posts a payload you define — JSON, raw or URL-encoded — with OAuth or API-key authentication, custom headers, conditional dispatch and defined behaviour when a request fails.
FormAssembly + Reporting
So the process can be measured, not just the volume. Response data is exportable and reachable through the REST API, which is how submission, approval and abandonment metrics get into a warehouse or a Salesforce dashboard.
Five stages from first audit to a system you can run
Durations below describe typical engagements and depend on how many forms, connectors and approval paths are in scope. We give you a fixed shape after stage one, not before it.
Audit & Discovery
We inventory existing forms, connectors, workflows and permissions, map the processes they support, and identify what is failing. Typically one to two weeks.
Architecture & Compliance Design
We design the data model, connector logic, workflow routing and compliance configuration — including the plan tier the requirement actually needs. One to three weeks.
Build & Connect
We build the forms and workflows, configure connectors against a sandbox, and test every failure path — not only the path where everything works. Two to six weeks.
Launch & Migrate
Controlled cutover with the legacy tool running in parallel where volume justifies it, plus admin training and documentation your team keeps. One to three weeks.
Operate & Extend
Connector monitoring, error triage, and new forms and workflows as processes change — on retainer, so the architecture stays coherent instead of accumulating exceptions.
What capture-to-CRM architecture looks like when it works
The engagement below is Twopir's own, on the same architectural problem this page describes: getting inbound capture into Salesforce with attribution intact. Alongside it is how one organization describes FormAssembly in FormAssembly's own published customer story.
US Enterprise — Legal, Financial & Insurance Services
Connecting inbound capture to Salesforce so every enquiry carries its source through to revenue.
100% Call attribution to campaign source
Auto Lead creation on every qualifying enquiry
Closed Loop reporting back to revenue
FormAssembly Customer Story
FormAssembly is a very high-utility tool for us because it’s plug-and-play. It would take us a significant amount of dev effort to build internally in Amazon, and we’d also spend a good amount of bandwidth maintaining that tool. With FormAssembly, you can just log in to Salesforce and create whatever forms you need.
Abhinav Singh Kakran Manager of Program Management, Amazon India — quoted in FormAssembly’s published case study, not a Twopir engagement
Eight FormAssembly services, each with its own depth
Most organizations need two or three of these, not all eight. Each page explains what that workstream involves, what it costs you to skip, and where it hands off to the others.
Implementation Services
Standing FormAssembly up from nothing: plan selection, instance and permission setup, first production forms, migration from a legacy tool, and handover. FormAssembly implementation services.
Integration Services
The multi-system view: which connector runs at which stage, how one submission reaches several destinations, and how failures are caught. FormAssembly integration services.
Salesforce Integration
The Salesforce connector in depth: prefill, lookups, deduplication, dynamic picklists, conditional writes, error handling and reprocessing. FormAssembly Salesforce integration.
Customization Services
Changing what the platform does without leaving it: themes and branding, translations, formulas, conditional logic, accessibility and custom JavaScript. FormAssembly customization services.
Form Automation
Everything that happens automatically within a single submission: prefill, calculations, notifications, e-signature, payment capture and save-and-resume. FormAssembly form automation.
API & Custom Integrations
For systems with no connector: the REST API, the webhook connector with OAuth or API-key auth, custom payloads, and middleware for retry and reconciliation. FormAssembly API and custom integrations.
Security & Compliance Consulting
Configuring for HIPAA, GDPR, GLBA, FERPA or FedRAMP obligations: plan tier, respondent authentication, masking, retention and audit evidence. FormAssembly security and compliance consulting.
Workflow Automation
Multi-form, multi-participant processes: workflow steps, approval chains, conditional routing and the connectors that run inside them. FormAssembly workflow automation.
A CRM firm that treats forms as part of the CRM
We help growing and mid-market companies solve complex CRM, integration and business system challenges, and we work with enterprise organizations on the same problems at larger scale. FormAssembly work sits inside that practice rather than beside it.
We design the record before we design the form
The object model, the matching rules and the ownership logic come first. A form built before those decisions will need rebuilding after them.
We are Salesforce and HubSpot practitioners, not form specialists
As a Salesforce Partner and HubSpot Partner, we can change either side of the integration. When the right fix is in Salesforce rather than in the form, we can make it.
We test the failure paths
Most connector incidents are not bugs — they are untested validation rules, permission gaps and record-type mismatches. We rehearse those before go-live, not after.
We say where configuration stops
Some requirements genuinely need code and some vendors will not say so. We tell you which side of the line you are on before the estimate, not during the build.
We treat compliance as configuration, not paperwork
A certified platform configured carelessly still fails an audit. We make the plan tier, authentication model, retention rules and access review part of the build.
Answers before the first call
A capable admin can build forms and a basic Salesforce connector without help, and many teams should. Consulting earns its place at the architecture decisions: how records are matched so submissions do not duplicate, which connector stage to run in, how failures are detected and reprocessed, and which plan tier your compliance obligations actually require. Those choices are hard to reverse once forms are live, which is why they are worth getting right the first time.
No. We implement FormAssembly; we do not resell it and we do not claim a FormAssembly partner tier. You buy your licence directly from FormAssembly, which means we have no commercial reason to recommend a larger plan than your requirements justify. Our partner credentials are with Salesforce and HubSpot, which is where the integration work lands.
It is driven by compliance and integration need rather than form volume. FormAssembly's current tiers are Essentials, Team, Enterprise and Government — renamed from the older Enterprise Cloud, Compliance Cloud and Government Cloud, so older comparison articles use names that no longer match the price list. Broadly: Salesforce integration and datasets start above the entry tier, identity-provider management for respondent SSO sits at Team and above, HIPAA and GLBA controls sit at Enterprise, and the FedRAMP-authorized High-Impact environment is the Government plan. We confirm the current tier definitions with FormAssembly during scoping rather than quoting from memory.
It can, but it should not always. Native forms are the right tool for simple marketing capture into a single object. FormAssembly earns its cost when you need prefill from existing records, writes across multiple related objects, conditional logic beyond a few branches, approval routing, payment capture, respondent authentication, or a compliance posture the native tools do not offer. A sensible architecture often keeps both and is explicit about which capture path belongs where.
With an audit, before changing anything. We inventory every form, connector, workflow and permission, identify which are actually in use, and check the connector logs for submissions that failed without anyone noticing. Inherited instances usually have three recoverable problems: duplicate records from missing lookup logic, orphaned submissions that never reached the CRM, and forms nobody owns. Those are fixable without starting over.
A focused piece of work — one process, a handful of forms, one connector — typically runs four to eight weeks from audit to live. A broader programme covering multiple departments, workflow approvals and a compliance review usually runs three to five months. The variables that move the timeline most are how clean the target data model is and how many approval paths need agreeing between teams, not the number of forms.
Yes, and it is common. Where another firm owns the CRM roadmap we scope our work to the collection layer and agree the interface between us in writing — which objects we write to, which validation rules we depend on, and who owns changes to them. The failure mode to avoid is two partners changing the same automation without telling each other, so we make that boundary explicit at the start.
Next Step
Bring us the process that keeps breaking, not the form
Tell us what happens after someone hits submit — where it stalls, what gets re-keyed, what the auditors asked for last time. That conversation is usually enough to tell you whether this is a configuration problem, an architecture problem, or neither.
Salesforce & HubSpot practitioners who treat collection as part of the CRM
