Formstack connects to a large ecosystem of business applications — CRM, finance, storage, payments, messaging and more. Making those connections work is easy; making them survive a renamed field, a timeout or a duplicate submission is the actual job. Twopir Consulting builds Formstack integrations to a written data contract, with matching keys, duplicate handling, retry behaviour and reconciliation defined before anything is switched on.
Formstack integration services cover designing, building and operating the connections between Formstack and the systems that hold your records. Formstack publishes integrations across a wide ecosystem of business applications — CRM platforms including Salesforce, HubSpot and Microsoft Dynamics; cloud storage such as Google Drive, OneDrive and Dropbox; payment processors including Stripe and PayPal; and automation platforms such as Zapier — alongside a REST API and webhooks for everything the packaged connectors do not cover.
The consulting work is not clicking connect. It is deciding which system owns which field, what key matches a submission to an existing record, what happens to a payload that cannot be delivered, and how anyone finds out when a connection stops working. Those decisions are what we mean by a data contract, and writing one down is the single practice that separates an integration estate you can change from one you are afraid of.
Teams usually default to the first pattern that works. The cost of that shows up later, in the form of an estate where every connection is a different shape and none of them can be monitored the same way.
| Pattern | How it works | Choose it when | Its limit |
|---|---|---|---|
| Native connector | A packaged Formstack integration configured in the form's settings, mapping fields to the target application. | The destination is one of the supported applications and the mapping is straightforward. | Error handling and retry behaviour are whatever the connector provides — which may not be enough for a critical path. |
| Webhook push | Formstack posts the submission to a URL you control at the moment it is submitted, secured with a shared secret or an HMAC signature. | You need the data immediately in a system with no packaged connector, and you can operate an endpoint. | You own delivery reliability: the receiving endpoint must handle duplicates, retries and downtime. |
| API pull | Your system polls the Formstack REST API for submissions on a schedule. | Batch processing suits the business rhythm, or the receiving system cannot accept inbound calls. | Latency, and API quota consumption — the Formstack API applies daily rate limits per access token. |
| Middleware or iPaaS | An integration platform sits between Formstack and the destinations, handling transformation, routing and retry centrally. | Several systems need the same data, transformation is non-trivial, or you already run an integration platform. | Another platform to licence, operate and secure — worth it at several connections, overkill at one. |
| Platform-native | The Salesforce-native packages write directly to Salesforce objects without an external hop. | Salesforce is the system of record and you want the data captured inside the org. | Salesforce-centred by design; serving other systems from the same capture needs additional work. |
Pick a house pattern and deviate deliberately. An estate where every connection follows the same pattern can be monitored, documented and handed over. One where each connection was built by whoever needed it cannot — not because any single choice was wrong, but because there is no shared way to tell whether any of them is working.
Eight questions per connection. They take an hour to answer during design and weeks to answer retrospectively during an incident.
Naming a system is not an integration. Each of these describes what actually moves, in which direction, and which team depends on it.
Submissions create and update records against standard and custom objects, and generated documents attach back to the record — so the team working the opportunity sees the intake data and the executed agreement in one place rather than in three. Covered in depth on our Formstack Salesforce integration page.
Form submissions create or update HubSpot contacts and can enrol them in workflows, so marketing owns one contact record rather than reconciling a CRM list against a form export. The integration requires a HubSpot plan with API access, and the Hub ID is configured on the form's integration settings.
Uploaded files and generated documents are written to Google Drive, OneDrive, Dropbox or Box under a folder structure derived from the submission — so a document can be found by anyone who knows the customer, not only by the person who filed it.
Card details are collected in PCI-compliant fields and processed by a PCI-compliant processor such as Stripe or PayPal, with the payment outcome written back alongside the submission — so finance can reconcile a transaction against the request that created it instead of against a bank statement.
Approved requests become purchase orders, invoices or supplier records in the finance system, usually through middleware or the API, with the finance reference written back so operations can see the financial status without logging into the finance system.
Onboarding and change-of-detail submissions update the employee record, and signed documents are filed to the employee file — so HR stops rekeying data that the employee already typed, and the acknowledgement evidence lives with the person it concerns.
Notifications and confirmations routed by logic to the right recipient, and operational alerts routed to the channel the responsible team actually watches — which is rarely the shared inbox the form was originally pointed at.
Zapier and similar platforms cover long-tail destinations quickly, moving a submission into a system that has no packaged connector. Useful for low-volume, non-critical paths; we recommend against them for anything a business process depends on, because the error handling is not yours to control.
A connection stops working and nothing announces it. The first signal is a customer asking why nobody replied, weeks later, by which point the backlog has to be reconstructed by hand from two systems.
Someone renames a field in the CRM. Three integrations that referenced it break, all silently, and the person who made the change had no way of knowing what depended on it.
No matching key was specified, so every submission creates a new record. The CRM degrades steadily, reporting becomes unreliable, and the eventual merge project costs more than the original build.
A timeout triggers a retry, but the first call had already succeeded. Without an idempotency mechanism, retrying an ambiguous failure creates a second record — which makes the retry worse than doing nothing.
Two systems both write the phone number. Whichever ran last is what everyone sees, and the value oscillates. Nobody is wrong, because nobody ever decided which system was authoritative.
Five connections, five patterns, five ways of failing and no common monitoring. Each one made sense when it was built; together they are a system nobody can reason about or hand over.
Every existing connection, what it moves, who depends on it and whether it is currently working. On inherited estates this step alone routinely finds connections nobody knew existed and one or two that stopped working months ago.
The eight questions answered per connection, signed off by the owner of each system involved. Field ownership disputes surface here, which is exactly where they should surface rather than in production.
Native connector, webhook, API, middleware or platform-native — decided against latency, volume, criticality and what you can realistically operate. Consistency across the estate is weighted heavily, because it is what makes monitoring possible.
Build against the contract, then test the failure paths deliberately: endpoint unavailable, malformed payload, duplicate delivery, quota exceeded, required field missing. A connection is not finished when it works — it is finished when its failures behave as specified.
Alerting to a channel someone owns, a failure queue that can be replayed, and a standing reconciliation comparing submissions against records created. Handed over with a runbook for each failure case we tested.
Yes, through three routes of increasing effort. Webhooks push a submission to an endpoint you control at the moment it is submitted, secured with a shared secret or an HMAC signature. The REST API lets your system pull submissions on a schedule. An integration platform sits in between and handles transformation and routing centrally. Which is right depends on latency, volume, how critical the path is, and — the question people skip — who will operate it at three in the morning when it fails.
For low-volume, non-critical destinations, it is a reasonable choice and much faster than building something. For anything a business process depends on, we advise against it. The reason is not quality — it is that the error handling, retry behaviour and failure visibility are not under your control, and a connection you cannot instrument is a connection you cannot be accountable for. Our rule of thumb: if somebody would notice within a day that it had stopped working, it should not be a general-purpose automation platform.
Define a matching key and an explicit behaviour when it matches. Email address is the usual default and a weak one — shared household and departmental inboxes match people who are not the same person, and anyone who changes email becomes a new record. Better keys are a customer or member number where one exists, or a composite of several attributes. Then decide deliberately what happens on a match: update the existing record, create a related record, or flag for human review. And specify what happens when two records match, because that case will occur.
Two mechanisms, and you need both. Alerting catches an active failure — an error response, an exhausted retry — and must go to a channel a named person actually watches. Reconciliation catches the silent case: a standing comparison of submissions received against records created over the same period. Alerting alone misses the failure mode where the integration reports success and writes nothing useful, which is the one that does the most damage because it can run for months.
Technically yes, and it is usually a symptom rather than a requirement. Writing the same submission into Salesforce and HubSpot means two systems now hold a record of the same thing, and unless one is explicitly authoritative they will diverge. The better design is normally a single system of record with the second system receiving a synchronised view, and the question of which is which is an organisational decision rather than a technical one. Where dual-write genuinely is the requirement — different business units, a migration in progress — it needs a conflict rule written down before it is built.
Most teams have one connection they quietly work around. Tell us which systems it joins and what it is supposed to move, and we will tell you whether it is broken, mis-specified, or working exactly as built and built wrong.
Integration design from a Salesforce Gold Partner and HubSpot Gold Partner — we design both ends of the connection, not just the Formstack side.
