Twopir Consulting stands FormAssembly up from nothing: the plan your compliance obligations actually require, the permission model, the first production forms and connectors, migration off whatever you are leaving, and an internal admin who can run it afterwards. Live in weeks, owned by your team, documented well enough to survive us leaving.
Trusted by 500+ organizations — including healthcare, higher education, nonprofit and financial services teams standing up secure data collection for the first time.
Built for Regulated Data Collection
Almost none of these are product problems. They are sequencing problems — work done in the wrong order, or decisions deferred until they became expensive. The cost shows up months after go-live, which is why it is rarely attributed to the rollout.
A form designed around what is convenient to ask produces a record nobody can report on. The object model, the matching rules and the ownership logic have to be settled first, or the forms get rebuilt after go-live.
The platform goes live, the consultants leave, and six months later nobody can say who is allowed to change a connector. Unowned instances accumulate duplicate forms faster than they accumulate submissions.
An old URL living in an email template, a printed PDF or a partner's website keeps collecting into a system nobody watches. Those submissions are invisible until someone asks why a record is missing.
Plan tier is driven by compliance obligation and integration need, not form volume. Teams routinely discover after purchase that respondent SSO, HIPAA controls or a FedRAMP environment sit on a tier they did not buy.
Everyone tests a clean submission. Nobody tests the duplicate, the required field a validation rule rejects, the record type the connector user cannot see, or the file that fails a malware scan — which is where live incidents actually come from.
A video shows what was built. It does not say why a mapping is the way it is, what happens when a connector fails, or which decisions are safe to change. That gap is what turns a working instance into an inherited mess.
A FormAssembly implementation is the sequence that takes an empty instance to a governed platform in production: selecting the plan tier the obligations require, configuring users, roles and permissions, agreeing the data model the forms will write into, building and testing the first production forms and connectors, migrating off the tool being replaced, and handing the result to a named internal owner with documentation they can use. It is bounded work with an end date, which is what distinguishes it from the ongoing services around it.
Where this page stops. Implementation gets you live. It does not cover every later change. Deepening a single connector — prefill, lookups, deduplication, error handling — is FormAssembly Salesforce integration. Connecting several systems to one submission is FormAssembly integration services. Changing look, logic or language inside an instance already live is FormAssembly customization services. Multi-step approval processes are FormAssembly workflow automation. Most organizations need implementation once and two or three of the others continuously.
What Twopir does, and what the product does. FormAssembly provides the platform, the connectors and the compliance certifications. Twopir designs and executes the deployment: the decisions about tier, structure, permissions, data model and cutover sequence, and the testing that proves it holds. We implement FormAssembly — we do not resell it, and your licence is bought directly from the vendor. Full product documentation is the FormAssembly Resource Center.
They run in this order for a reason. Each one closes a decision the next one depends on, which is why an implementation that starts with form building usually ends up repeating it.
We establish what is actually being collected, who may see it, and which obligations apply — then map that to a plan tier rather than the other way round.
The record a form creates matters more than the form. We settle object structure, matching rules and ownership before anything is built.
Users, roles and access configured so the instance is governable on day one instead of being tightened after an audit finding.
The first production forms and their connectors, built against a sandbox and tested on the paths that actually break.
Moving off the previous tool without stranding submissions or leaving live links pointing somewhere nobody is watching.
Your admin leaves the engagement able to build, change and troubleshoot — including the first time something fails in production.
We run this against every form in the existing inventory before rebuilding anything. In a typical inventory it removes a substantial share of the scope, because dormant and duplicated forms are cheaper to retire than to port.
| What we find | Decision | What it costs to get wrong |
|---|---|---|
| In active use, feeds a system of record | Rebuild, with the data model reviewed first. | Porting the old mapping unchanged carries its defects forward. |
| In active use, output goes only to email | Rebuild and connect it properly — this is the upgrade. | Rebuilt as-is, it stays a process nobody can report on. |
| Several near-identical variants | Consolidate to one form with conditional logic. | Five forms to maintain, five places for a rule to drift. |
| Seasonal, submits a few times a year | Rebuild, but after go-live, not before. | It delays cutover for traffic that is months away. |
| No submissions in twelve months | Retire. Archive the historical responses. | Rebuilding it is pure cost with no user. |
| Live URL embedded outside your control | Redirect, and keep the old form reachable until traffic stops. | Submissions land in an abandoned system and are never seen. |
Durations describe typical engagements and depend on the number of forms, connectors and approval paths in scope. You get a fixed shape after stage one, not before it.
Inventory of existing forms with real submission counts, the processes they support, the data being collected and the obligations that attach to it. One to two weeks.
Data model, connector placement, permission design and the plan-tier recommendation — written down and agreed before any build starts. One to two weeks.
Instance setup, roles and themes, then the production forms and connectors built against a sandbox and tested on the failure paths. Two to four weeks.
Historical export, link and embed redirection, parallel run where volume justifies it, then cutover with the old tool switched off deliberately rather than forgotten. One to two weeks.
Working sessions with your admin, documentation, the incident runbook, and an agreed support arrangement if you want one. One week, then optional retainer.
These are the four sectors where we most often stand FormAssembly up, and the processes that tend to go first — chosen because they are high volume, high consequence, or both.
Prospective-student applications, scholarship submissions and student surveys — high seasonal volume, heavy conditional logic, and records that must reach the student system without re-keying.
Patient intake and information forms handling protected health information — the deployment where plan tier, the business associate agreement and file handling have to be settled before the first form is built.
Donation forms, volunteer sign-ups and onboarding documents — usually a small team, so the deciding factor is whether one person can own the platform afterwards without a specialist.
New account applications, loan processing and KYC data collection — where the audit trail, retention rules and evidence of who saw what matter as much as the submission itself.
We’re building up a really powerful database, and we’ll be able to do some pretty powerful marketing going forward.
We have not published a FormAssembly-scoped case study, and we will not present one that does not exist. The closest published evidence of how we architect capture into Salesforce is this integration engagement.
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.
The inventory comes first and it usually removes a third of the forms. Rebuilding something nobody submits is the easiest cost to avoid and the one most often missed.
As a Salesforce Partner and HubSpot Partner, when the right fix is a record type or a validation rule rather than a form field, we can make it rather than file a request.
We do not resell FormAssembly, so we have no reason to recommend a larger tier than the obligations justify — or a smaller one that cannot hold the data you collect.
Duplicates, rejected validations, permission gaps and record-type mismatches get rehearsed before go-live. That is where live incidents come from, and they are cheap to find early.
Handover means a named owner who can build, change and troubleshoot — including the first production failure. If that is not true, the implementation is not done.
A first deployment covering one department — a handful of production forms, one connector and an admin handover — typically runs four to eight weeks from audit to live. Adding workflow approvals, a second system of record or a compliance review usually takes it to three or four months. The variable that moves the timeline most is how clean the target data model is: if Salesforce objects, record types and validation rules need redesigning first, that work sets the pace, not the form building.
Four things, and none of them full time. A process owner who can decide how an exception should be handled, a CRM admin with a sandbox and the access to change objects and validation rules, a compliance or security contact if regulated data is in scope, and someone who will own the platform after go-live. That last one matters most — implementations that fail usually fail because nobody internal was named as the owner until the consultants had left.
Yes, and it is a common starting point. Migration is three separate jobs: rebuilding the forms, moving or archiving historical submissions, and redirecting the links and embeds that point at the old tool. The third is the one teams forget — an old form URL living in an email template, a PDF or a partner's website will keep collecting into a system you have stopped watching. We inventory those before cutover and run both tools in parallel where submission volume justifies it.
No, and you usually should not. In most inventories a third of the forms are genuinely in use, a third are seasonal or duplicated, and a third have not been submitted in a year. We check actual submission counts before rebuilding anything, consolidate the duplicates, and retire the rest. Rebuilding a form nobody submits is the cheapest scope to cut and the easiest one to miss.
Ideally none — let the requirements pick the tier. Plan choice is driven by compliance obligation and integration need rather than form volume, and FormAssembly renamed its tiers to Essentials, Team, Enterprise and Government, so older comparison articles cite names that no longer match the price list. Broadly: Salesforce integration and datasets sit 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 current tier definitions with FormAssembly during scoping rather than quoting from memory, and you buy the licence directly from them.
Documentation of what was built and why, the connector mapping in a form your admin can read without opening the connector, a runbook for the failure cases we tested, and working sessions rather than a recorded demo. We also agree what happens the first time a connector fails in production — who sees it, where they look, and how a failed submission is reprocessed. An implementation that cannot survive its first incident without us was not finished.
A list of what you collect today, and roughly how often, tells us more in ten minutes than a specification does in a week. From it we can usually say what the deployment looks like, which plan tier your obligations point to, and how much of the existing estate is worth rebuilding.
Or contact the team — Salesforce & HubSpot practitioners who deploy collection as part of the CRM
