Native or Connected Is the Decision Everything Else Inherits

Partly, and the distinction matters. Formstack offers Salesforce-native managed packages — Forms for Salesforce and Documents for Salesforce — that install from AppExchange and run inside your org, collecting and storing data under Salesforce's own security model. It also offers cloud products that run on Formstack's own platform and connect to Salesforce through integrations. Saying "Formstack is native" without specifying which products you mean is the ambiguity that causes most of the architecture mistakes we are called in to fix.

It depends entirely on the deployment model, which is why the decision matters. With the Salesforce-native packages, data is collected, processed and stored inside your org — it does not have to leave it to be captured. With the connected cloud products, data is captured on Formstack's platform, which Formstack hosts on AWS in the United States, and then synced into Salesforce. If your data residency, privacy or sector obligations restrict where personal data may be processed, this is the first question to settle, before any form is designed.

Formstack documents a minimum of two calls per submission for Forms for Salesforce — one to authenticate against your org and one to create the primary object record — with additional calls triggered by options such as dependent fields and related objects. The practical consequence is that a high-volume public form is a capacity decision, not just a design decision. We model expected consumption against your org's allocation during design, and where the number is uncomfortable we look at batching, at reducing related-object writes, or at whether that particular capture belongs in the connected model instead.

Yes. Formstack provides a Lightning component that you drag into the Experience Builder and point at the form, which places it on the site without custom code. The work that actually needs attention is the access model underneath it: an Experience Cloud form runs as the site's guest or authenticated user, so object permissions, field-level security and sharing have to be designed for that user rather than inherited from an internal profile. Prefill in a portal context can also be driven from a record list component, which is a cleaner pattern than passing identifiers in a URL.

Yes. Documents for Salesforce can merge from Salesforce data and be triggered from a button on an object, from Flow, or from a form submission. It can also generate from a Salesforce report — producing a document per row and optionally combining them into a single file — and it offers a high-volume generation capability that uses Salesforce's Batch Apex framework so large runs stay inside platform governor limits. Output can be attached back to the originating record, sent to storage, or routed onward for signature.

That is the most common reason we are engaged on this specific work. The first step is reconciliation: compare submissions received against records created and documents attached over a defined period. That single check usually separates "the integration is broken" from "the integration works and the mapping is wrong", and the two need very different responses. From there we produce a findings list ranked by data risk, and remediate in that order rather than rebuilding first.