Building in Production
There is nowhere to test failure cases, nowhere to regression-test the next package update, and no rollback. Install to a sandbox even for something that looks trivial — especially for something that looks trivial.
Technical Guide
Formstack Salesforce Integration Guide: Decisions, Setup and Testing
This guide walks through integrating Formstack with Salesforce end to end: choosing between the Salesforce-native managed packages and the connected cloud products, installing and configuring, mapping objects and fields, setting up prefill, publishing to the right surface, budgeting API consumption, and testing properly before go-live. It is written for the person doing the work.
Last updated 18 September 2026
Setup Sequence Twopir · 2πr
Layer 01
Before You Install Anything
API Access & Edition Target Objects Sharing Model Volume Estimate
Layer 02 · 2πr
The Build Sequence
Install & Connect Map & Prefill Publish & Test
Layer 03
Ready for Go-Live
Reconciled Documented Reversible
Written For Salesforce admins and architects
How Do You Integrate Formstack With Salesforce?
Integrating Formstack with Salesforce is a seven-step sequence: choose a deployment model, confirm the org prerequisites, install and connect the packages in a sandbox, map objects and fields, configure prefill, publish to the right surface, then test the failure paths before go-live. The first step is the one that constrains all the others, and it is the step most projects skip.
This guide covers each of those in order, with the decisions to make at each point and the mistakes that are expensive to reverse. It assumes you are comfortable in Salesforce Setup. Where a figure is quoted, verify it against current Formstack documentation for your plan and package version — this material changes between releases.
If you want the service rather than the instructions, the commercial version of this page is Formstack Salesforce integration, which covers how Twopir Consulting delivers the same work. This page is deliberately instructional and is here so you can do it yourself.
Choose the Deployment Model Before Anything Else
Formstack offers two architecturally different ways to work with Salesforce. Forms for Salesforce and Documents for Salesforce are managed packages installed from AppExchange that run inside your org, collecting and storing data under Salesforce's own security model. Formstack's cloud products — Formstack Forms, Documents and Sign — run on Formstack's platform and connect to Salesforce through integrations.
Reversing this choice after go-live means migrating submissions and rebuilding integrations, so answer these four questions first:
- Is Salesforce the definitive system of record for this process? If yes, native is usually correct.
- Does the same capture need to serve systems outside Salesforce? If yes, the connected model is normally better suited.
- Do you have data residency or privacy constraints on where personal data is processed? Native keeps capture inside your org; connected means data is processed on Formstack's platform, which Formstack hosts on AWS in the United States.
- What volume will this carry? Native consumes Salesforce API capacity per submission, which at scale is a budget line rather than a footnote.
Write the answer down along with the reasoning. Six months later, when someone asks why the org works this way, that note is what prevents the decision being quietly reversed by somebody who does not know the constraints.
Two packages, not one. Formstack's native form builder and Formstack Documents are separate AppExchange managed packages. Installing one does not install the other. If your design needs both capture and document generation inside the org, plan for two installations, two configuration exercises and two upgrade paths.
Confirm the Org Prerequisites Rather Than Assuming Them
Each of these has stopped a build in progress at least once. All are quick to check and expensive to discover late.
API access Forms for Salesforce requires org API access. Generally present in Enterprise, Unlimited and the industry clouds; confirm explicitly on Group and Professional editions, where it is not a given.
Edition-dependent features Some editions do not support Author Apex or invoking Apex classes, which affects auto-generated prefill links. Publishing forms to URLs relies on Salesforce site domains, which are not available in every edition.
Target objects Identify the primary object, any child objects, the record types in play and the relationships between them. Writing everything to Lead because it is easiest is the decision you will regret first.
Existing automation Review validation rules, triggers, flows and required fields on the target objects. Any of them can reject a write, and if that rejection is not surfaced the form will report success while writing nothing.
Sharing and field-level security Determine which user context the form will run as, particularly for Experience Cloud, and confirm that user's object permissions, field-level security and sharing actually permit the intended writes.
Volume and API budget Formstack documents a minimum of two API calls per submission — authentication plus creating the primary record — with more for dependent fields and related objects. Multiply by expected volume and compare against org capacity.
File upload limits Formstack documents a default maximum file size for native forms that can be raised on request. If your process involves large attachments, confirm the current figure before designing around it.
Form size Formstack recommends keeping forms below roughly 400 fields to avoid mapping failures. A form approaching that is almost always three processes wearing one form's clothes.
Install in a Sandbox, Then Map Deliberately
Installing the packages
A Salesforce administrator installs from AppExchange — open the marketplace from within Salesforce, find the Formstack listing, and install into a sandbox first. Remember that the native form builder and Formstack Documents are separate packages, each installed independently.
Install to a sandbox even when you are confident. You need somewhere to test the failure paths, somewhere to regression-test the next package update, and somewhere to break things without a customer noticing.
Permissions after install
Assign the package's permission sets to the users and integration contexts that need them, and check field-level security on the specific fields you intend to write. A permission gap here produces a failure that looks like a mapping problem, which is why it costs disproportionate time to diagnose.
Mapping objects and fields
Map the primary object first, then child objects. Formstack's mapping interface supports mapping from primary and child objects, with SOQL available where the data structure is more complex than the interface can express. Work through these in order:
- Primary object and record type. Confirm the record type is set explicitly rather than falling to a default, because the default varies by the running user's profile.
- Matching key and duplicate behaviour. Decide what identifies an existing record and what happens on a match. Do not default to email address without considering shared inboxes and address changes.
- Child and related records. Each additional related object adds API calls per submission — worth knowing before you add the fifth one.
- Picklist alignment. Form option values must match the Salesforce picklist values exactly, or the write fails or silently stores something unexpected.
- Dependent fields. Supported, with documented capabilities and limitations, and they consume additional API calls. Read the current limitations before designing a deeply dependent structure.
Write the mapping down
Produce a field-level mapping document as you build, not afterwards. It is the artefact that lets somebody assess the impact of renaming a Salesforce field two years from now, and it is the single cheapest piece of documentation in the whole build.
Prefill: Four Options, Different Security Properties
Prefill is the feature that makes a form feel like part of a system rather than a questionnaire. It is also the feature most likely to expose data you did not intend to expose.
| Option | How it works | Use it when | Security property |
|---|---|---|---|
| Dynamic Prefill | Enabled in the form's publish options at object level; pulls live record data at render rather than passing values in the URL, so the data is current when the form is refreshed. | The default choice for anything drawing on Salesforce data. | Strong — values are not exposed in the link. |
| Prefill links generated from Flow | A record-triggered Flow generates the prefill link, typically for an outbound journey such as a renewal or data-refresh request. | You are sending a personalised link to a known individual. | Depends on what the link carries — combine with Dynamic Prefill rather than embedding values. |
| Experience Cloud record list | Prefill driven from a record list component inside the Experience Cloud site, where the user's identity and access are already established. | Authenticated portal users selecting a record to act on. | Strong — governed by the site's own access control. |
| URL parameters | Values passed directly in the query string of the form link. | Non-sensitive values only — a campaign code, a language preference. | Weak — any recipient can read and alter them. |
Note the edition dependency. Auto-generated prefill links rely on Apex, and some Salesforce editions do not support Author Apex or invoking Apex classes. If you are on one of those editions, confirm which prefill options are actually available to you before the design depends on one.
Publishing, and the Access Model Underneath It
Experience Cloud
Formstack provides a Lightning component that you drag into Experience Builder and point at the form. Placing the form is genuinely a drag-and-drop operation. The work that needs attention is underneath it: the form runs as the site's guest or authenticated user, so object permissions, field-level security and sharing rules must be designed for that user rather than inherited from an internal profile.
Test with an actual portal user account, not by previewing as an administrator. Preview as an admin is the single most common reason a portal form works in testing and fails on launch day.
Internal Lightning pages
For staff-facing forms, embedding on a record page puts the form in the context the user is already working in, with both identity and record known. Be sceptical of internal forms that re-collect fields already present on the record — that is usually a process problem being solved with a form.
Public web publishing
Publishing forms to URLs relies on Salesforce site domains, which are not available in every edition — Professional Edition in particular. Confirm this before promising a public form on the native model. Where it is not available, the connected cloud product is the usual answer, which loops back to the deployment decision in step one.
Branding
Apply a theme rather than styling each form individually. A theme is applied once and inherited, and it is what stops a form estate looking like it was built by six different people over four years — which, usually, it was.
Test the Failure Paths, Then Run the Go-Live Checklist
A form that works when everything goes right is not tested. These are the cases that actually occur in production, and each one has a correct behaviour you should have chosen deliberately.
| Test | What you are checking | What good looks like |
|---|---|---|
| Duplicate submission | The same person submits twice. | The configured matching behaviour occurs — update, related record or review — not a silent second record. |
| Validation rule rejection | A submission that a Salesforce validation rule or trigger will reject. | The failure is surfaced somewhere a human will see it. A success message over a failed write is the worst possible outcome. |
| Missing required data | A required Salesforce field has no corresponding value in the submission. | Either the form prevents it, or the write fails visibly. Never a partially populated record that looks complete. |
| Portal user context | A real Experience Cloud user — guest or authenticated — submitting the form. | The write succeeds with that user's permissions, and the form exposes nothing that user should not see. |
| Prefill access | A prefill link opened by someone other than the intended recipient. | No data is exposed that the opener is not entitled to. If a URL parameter can be edited to reveal another record, the design is wrong. |
| Volume and API budget | Realistic peak submission volume against org API capacity. | Consumption sits comfortably inside the allocation, with headroom for the rest of the org's integrations. |
| Document generation | A merge with extreme real data — long names, many line items, missing optional values. | Layout holds, no blank where a value should be, and the file lands where it was configured to land. |
| Reconciliation | Submissions received compared against records created over a test period. | The counts match exactly. Any discrepancy is understood before launch, not after. |
Go-live checklist
- All test cases above pass in a sandbox with production-like data.
- Field-level mapping is documented and stored where the team will find it.
- The deployment decision from step one is recorded with its reasoning.
- A standing reconciliation report is scheduled with a named owner.
- Failure alerting goes to a channel a named person actually watches.
- A rollback position is defined and has been tested, not just described.
- Access has been verified as the real user type, not previewed as an admin.
- Retention configuration matches your stated policy for the data being collected.
- The team that will own this has been walked through the build, not sent a recording.
Six Mistakes Worth Avoiding Specifically
Writing Everything to Lead
Lead is the path of least resistance and rarely the right destination. Choosing it by default means a migration later, at a point when there is production data and dependent reporting to move with it.
Previewing as an Administrator
An admin preview tells you the form renders. It tells you nothing about whether a guest or portal user can submit it. Test as the actual user type or expect to find out on launch day.
Prefill via URL Parameters
Convenient, and it puts your data in a string anyone can read and edit. For anything sensitive, use Dynamic Prefill so values resolve server-side against the record instead of travelling in the link.
Ignoring the API Budget
At minimum two calls per submission, more with dependent fields and related objects. On a high-volume public form that is a capacity decision. Discovering it as an outage is considerably more expensive than modelling it.
No Reconciliation After Launch
Without a standing comparison of submissions against records created, a partial failure is invisible. This is the cheapest control on the list and the one most consistently missing.
Questions That Come Up Mid-Build
A Salesforce administrator opens the AppExchange marketplace from within Salesforce, searches for Formstack, finds the listing and installs the package into a sandbox or production org. Install into a sandbox first. Note that the native form builder and Formstack Documents are two separate managed packages that each need to be installed individually — installing one does not give you the other. After installation, assign the package permission sets and verify field-level security on the fields you intend to write to.
Dynamic Prefill is enabled in the form's publish options, where you choose to prefill at object level and select the prefill source. Because the data is pulled at render time rather than passed in the URL, the values are live and current when the form is refreshed. In an Experience Cloud context the prefill source can be a record list component, which is a cleaner pattern than passing an identifier in a link. For outbound journeys, a record-triggered Flow can generate the prefill link — combine that with Dynamic Prefill rather than embedding values in the URL.
Work through four causes in this order. A validation rule, required field or trigger on the target object is rejecting the write. The running user — particularly a guest or portal user — lacks object permission or field-level access. A picklist value submitted by the form does not exactly match the Salesforce picklist. Or the org has exhausted its API allocation. The Salesforce debug logs and the package's own error surface will usually identify which within minutes; the reason this takes people hours is that they start by rechecking the mapping, which is rarely the cause.
Yes. The Formstack Documents managed package includes a Visualforce page for populating documents from Salesforce reports, generating an individual document per row and optionally combining them into a single file for delivery. For larger runs, the high-volume generation feature uses Salesforce's Batch Apex framework with a configurable batch size up to the platform maximum of 200 records per batch, which is what keeps a large run inside governor limits. Before relying on it at scale, test what happens when a record mid-run fails — whether the run stops, continues or is resumable is the property you actually need to know.
Install the update into a sandbox first and run a written regression checklist against it before touching production. The checklist should name each customization and integration specifically — "confirm the cross-field validation on the claims form still blocks submission" rather than "test the forms". This matters because Formstack ships package updates that include compatibility with each Salesforce seasonal release, so staying current is not optional in the long run. An org that cannot take package updates falls further behind every quarter, and the cost of catching up grows faster than the cost of staying current.
Go Further
Parent Formstack Salesforce Integration The commercial counterpart: how Twopir Consulting delivers this work, and the full deployment comparison. Practice Formstack Consulting Services Every engagement type across the Formstack Suite, and where each one fits. Documents Formstack Documents Implementation Template architecture, merge field mechanics and high-volume generation in more depth. Beyond the package Formstack API & Custom Integrations When the packaged Salesforce path cannot express the requirement and code is the answer.
If You Get Stuck
Most of This Is Doable In-House. Some of It Is Worth a Second Opinion.
The steps in this guide are within reach of a capable Salesforce admin. The two places teams most often want a second opinion are the deployment decision in step one and the API budget in step two — because both are expensive to get wrong and cheap to check.
Platform behaviour, edition prerequisites and published limits change between releases. Verify anything in this guide against current Formstack documentation for your plan and package version before you rely on it.
