One connector failed and nobody was told
Three destinations succeeded, the fourth did not, and the respondent saw a thank-you page. The record is now inconsistent across systems and the only evidence is a log entry nobody reads.
FormAssembly · Integration Architecture
One submission. Four systems. Nobody agreed which one wins.
Connecting FormAssembly to one system is configuration. Connecting it to Salesforce, HubSpot, a payment processor and an internal application — from the same submission, without leaking data into systems that should not hold it — is architecture. Twopir Consulting designs that layer, including what happens when one connector fails and the rest succeed. Routed deliberately, mapped explicitly, monitored on purpose.
12+
500+
40+
250+
Trusted by 500+ organizations — including healthcare, higher education, nonprofit and financial services teams whose submissions have to reach more than one system.
Built for Regulated Data Collection
- Salesforce Partner
- HubSpot Partner
- Connector Architecture
- Multi-Destination Routing
- Payment Connectors
- Webhook Integration
- Error Handling & Reprocessing
- Marketing Cloud
Six failures that only appear once a second system is connected
A single connector is forgiving. The moment a submission has more than one destination, the questions of ordering, ownership and partial failure all arrive at once. None of them have a default answer worth accepting.
Two systems both think they own the contact
Salesforce and HubSpot each write the same person from the same form, with different matching rules. Neither is wrong on its own terms, and the two records drift apart from the first submission.
Every destination receives the whole submission
The simplest mapping sends everything everywhere. That is how health information reaches a marketing platform, and how a payment reference ends up in a system with no business holding it.
The connector runs at the wrong stage
Anything placed after submission runs once the respondent has already been redirected. For a payment confirmation or an eligibility check, that means telling someone it worked before knowing whether it did.
There is no reconciliation, only hope
Nobody can answer how many submissions in the last quarter reached every intended system. Without a reconciliation view, a partial failure is only discovered when a customer complains.
A change in one system silently breaks another
A retired picklist value, a new required field or a tightened validation rule in the CRM will stop a connector that has worked for a year. Nothing in the form changed, so nobody looks there.
What This Covers
Integration is a routing problem before it is a mapping problem
FormAssembly integration work is the design of what happens to a submission after it is made: which connectors run, in which order, at which stage of the submission's life, what each destination is permitted to receive, which system owns a field when two of them disagree, and how a partial failure is detected and corrected. Field mapping is the visible part and the smallest part. The decisions that determine whether the integration holds up are made before a single field is mapped.
Where this page stops. This page is about several systems on one submission. Going deep on the Salesforce connector alone — prefill, lookups, deduplication, dynamic picklists, conditional writes — is FormAssembly Salesforce integration. Building against the REST API or writing middleware for a system with no connector is FormAssembly API and custom integrations. Standing the platform up in the first place is FormAssembly implementation services, and routing a process across several forms and approvers is FormAssembly workflow automation.
What Twopir does, and what the product does. FormAssembly provides the connectors, the stage model and the connector logs. Twopir decides how your organization uses them — the routing design, the ownership rules between systems, the failure policy per connector, and the reconciliation that proves it is working. We implement FormAssembly and hold partner credentials with Salesforce and HubSpot, which is where most of this work actually lands. Product documentation is the FormAssembly Resource Center.
Which stage a connector runs in changes what the respondent is told
This is the decision most often left at its default, and the one that causes the most expensive incidents. Each connector gets this choice made deliberately, per connector, and written down.
| Stage | Use it for | What goes wrong if misplaced |
|---|---|---|
| Form opened | Prefilling from existing records, and loading options the form needs before it is answered. | A slow or failing lookup here blocks the form itself, so the respondent sees an error before they start. |
| Form submitted | Anything the respondent needs confirmed: the record write, the payment, an eligibility check. | Too much work here makes submission slow; too little means people are told something succeeded before it did. |
| After form submitted | Slow or non-critical follow-on steps — notifying a secondary system, warehouse copies, internal alerts. | The respondent is redirected first, so a failure is invisible to them and only surfaces in the log. |
| Field group | System of record | How the other system gets it |
|---|---|---|
| Identity and contact details | Usually the CRM holding the operational relationship. | Written once on creation, then synced rather than overwritten on every submission. |
| Marketing consent and source | The marketing platform, where the preference is acted on. | Mirrored to the CRM as read-only context for the person handling the record. |
| Operational or case data | The CRM that runs the process. | Not sent to marketing at all unless a specific campaign needs it. |
| Regulated or sensitive data | The system whose plan and controls cover it. | Withheld from the others by mapping, not by policy alone. |
| Payment and transaction references | The payment processor. | Reference only on the CRM record — never the instrument details. |
The destinations, and what actually moves in each direction
Naming a platform is not an integration. For each one below: what problem the connection solves, what data crosses, in which direction, and which team consumes it.
Salesforce
So the operational record is created once and correctly. Outbound on open: the form reads Contact, Account and related records to prefill. Inbound on submit: creates or updates standard and custom objects. Service and operations teams consume the result; failures land in the connector log for reprocessing.
HubSpot
So marketing keeps automation without holding data it should not. Inbound on submit: creates and updates contacts and associated records. Marketing consumes consent, source and campaign context; the operational and regulated fields are withheld by mapping rather than by policy.
Payments — Stripe, PayPal, Authorize.Net
So the money and the record it belongs to are created together. Outbound on submit: the payment is taken by the processor, which holds the instrument details. Inbound: only the transaction reference returns to the CRM record, which is what finance and service need to reconcile.
Salesforce Marketing Cloud
So journeys start from verified data rather than a list upload. Forms prefill from and write to Marketing Cloud records; where a native path does not exist for Account Engagement, the webhook connector carries the payload instead. Campaign teams consume the result.
Internal & Legacy Systems
So a homegrown system is not the reason a process stays on paper. Outbound on submit or after: a defined JSON, raw or URL-encoded payload over an authenticated webhook, with custom headers, conditional dispatch and a stated behaviour when the request fails.
Warehouses & Reporting
So the process itself can be measured, not just its volume. Outbound after submission: response data reaches a warehouse through export or the REST API, which is how abandonment, cycle time and per-channel record quality become reportable.
From connector inventory to a reconciled pipeline
Durations describe typical engagements and depend on how many destinations and how much existing configuration are in scope. You get a fixed shape after stage one.
Connector Inventory
Every existing connector, its stage, its mapping and its recent log history — including the failures nobody had noticed. One to two weeks.
Routing & Ownership Design
Which destination receives what, which system owns each field, what stage each connector runs in, and the failure policy for each. Written down and agreed. One to two weeks.
Build & Failure-Path Testing
Mapping built against a sandbox, then tested on duplicates, rejected validations, permission gaps, retired picklist values and failed uploads. Two to four weeks.
Monitoring & Reconciliation
A view that answers how many submissions reached every intended destination, plus alerting so a partial failure is found by you rather than by a customer. One week.
Handover & Change Control
Documentation, the incident runbook, and an agreed process for CRM-side changes that would break a connector — the failure mode that returns most often. One week, then optional retainer.
What capture-to-CRM architecture looks like when it holds
The engagement below is Twopir's own, on the same architectural problem: getting inbound capture into Salesforce with attribution intact and nothing lost between systems. Beside it, how one organization describes the connector layer in FormAssembly's own customer story.
US Enterprise — Legal, Financial & Insurance Services
Every qualifying enquiry creates a record automatically, carries its campaign source, and reports back to revenue when the deal closes.
100% Call attribution to campaign source
Auto Lead creation on every qualifying enquiry
Closed Loop reporting back to revenue
FormAssembly Customer Story
It’s very cool. The forms can talk to Salesforce, create and update objects.
Niek van Hengel Co-Founder, Granny’s Finest — quoted in FormAssembly’s published case study, not a Twopir engagement
We can change both ends of the integration
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.
Most connector incidents are CRM-side
A retired picklist value or a tightened validation rule stops a connector that worked for a year. As a Salesforce Partner and HubSpot Partner we can fix the cause, not just the symptom.
We decide the failure policy per connector
Whether a failure stops the remaining steps or lets them continue is a business decision with a different answer for a payment than for a notification. We make it explicitly rather than accepting a default.
We map for least privilege
Every destination receives only what it should hold. Withholding sensitive fields by mapping is enforceable; withholding them by policy is a promise.
We build the reconciliation view
You should be able to answer how many submissions reached every intended system last quarter. If nobody can, partial failures are being discovered by customers instead.
We agree change control at handover
The most repeatable failure is a CRM change nobody told the integration owner about. We set that process up before we leave, because it is the one that keeps recurring.
The questions that decide the architecture
Yes, and that is the case this page exists for. A single form can run several connectors, and different parts of the same submission can go to different destinations — marketing fields to HubSpot, the operational record to Salesforce, a payment to Stripe or PayPal, and a payload to an internal system over a webhook. The architecture question is not whether it can be done but what each destination is allowed to hold: sending the whole submission everywhere is the most common way sensitive data ends up somewhere it should not be.
That is the scenario worth designing for, because it produces a half-written state rather than a clean failure. FormAssembly logs each connector run, so a failure is visible and the response can be corrected and reprocessed — on Essentials plans and above, responses can be reprocessed in bulk. What matters is the design around that: which connector runs at which stage, whether a failure should stop the remaining steps or let them continue, and who is told. We make that an explicit decision per connector rather than leaving it at the default.
Because it decides what the respondent experiences when something goes wrong. Connectors can run when the form is opened, when it is submitted, or after submission. A connector in the after-submitted stage runs once the respondent has already been redirected to the thank-you page, so they are told everything succeeded whether or not it did. That is the right choice for slow, non-critical steps and the wrong choice for anything the person needs confirmed — and it is the single most common cause of submissions that exist in FormAssembly but never reached the CRM.
Yes. FormAssembly's HubSpot connector, launched in 2025, creates and updates HubSpot records from a submission and can run alongside a Salesforce connector on the same form. Organizations running both platforms usually want marketing capture in HubSpot and the operational record in Salesforce, which makes the mapping decision — which system owns which field, and which one wins on conflict — more important than either connector's configuration.
Yes, through the webhook connector, which posts a payload you define to any endpoint with OAuth or API-key authentication, custom headers and conditional dispatch. That covers most homegrown and legacy systems. Where the target needs data transformed, needs guaranteed delivery, or needs a reconciliation record, we put middleware between the two rather than pushing that logic into the form. That deeper work is covered on our FormAssembly API and custom integrations page.
Against a sandbox, on the paths that actually break. A clean submission almost always works; what fails in production is the duplicate that matches two records, the required field a validation rule rejects, the record type the connector user cannot see, the picklist value that no longer exists, and the file that fails a malware scan. We rehearse those before launch and document what each one does, so the first production incident is one your team has already seen.
Your admin, with documentation written for that purpose. We hand over the connector mapping in a form that can be read without opening the connector, the reasoning behind each design decision, and a runbook covering the failure cases we tested — including where to look in the connector log and how to reprocess a failed response. Retained support is available where the integration surface keeps growing, but it should be a choice rather than a dependency.
Next Step
Open your connector log and read the last month
If there are failures in there nobody has actioned, that is the conversation to have. Bring us the log and the list of systems a submission is supposed to reach, and we can usually tell you where the architecture is leaking before any engagement starts.
Or contact the team — Salesforce & HubSpot practitioners who own both ends of the integration
