A form is the narrowest point in your process — everything downstream inherits whatever it collects. Twopir Consulting designs, builds and integrates Formstack Forms as part of your Salesforce architecture: the field model, the conditional logic, the prefill, the routing and the records it creates. Scoped, built and supported by the same team that owns the CRM it feeds.
Trusted by 500+ organizations — we help growing and mid-market companies solve complex CRM, integration and business system challenges, and we serve enterprise teams running Formstack at scale.
Where Formstack Forms Work Lands
Almost nobody calls us because a form is broken. They call because reporting cannot be trusted, onboarding takes too long, or an audit asked a question the system could not answer. Trace any of those back far enough and you arrive at the capture layer.
Free-text where a picklist belonged produces dozens of spellings of the same answer. The cleanup is permanent, because new variants arrive faster than anyone can standardise the old ones — and every report built on that field inherits the problem.
A client who has been on your books for three years is asked for their address again. It is friction, it produces two conflicting versions of the truth, and it tells the customer your systems do not talk to each other.
Five near-identical regional forms mean five things to update when the wording changes and five data sets that will not report together. Creating a form is easy; retiring one has no owner, so the estate only ever grows.
The submission emails a shared inbox. Nobody owns it, two people reply or neither does, and no decision is recorded. A notification is not a workflow — and treating it as one is how work goes missing between teams.
Data is captured once, then typed again into a contract, an agreement or a welcome pack. Each retype is a chance to introduce an error into a document a client will sign — and a reason the document cannot be traced back to the record that produced it.
A platform that supports accessible, HIPAA-aligned or consent-compliant forms does not produce them automatically. Unlabelled fields, colour-only error states and retention nobody set are all still yours — and they surface during an audit, not before one.
Formstack Forms is a no-code form builder and data-capture product from Intellistack (the company formerly called Formstack). It collects structured data through online forms, validates it at the point of entry, applies conditional logic, takes payments, and routes each submission to the people and systems that need it. On Salesforce it also ships as Forms for Salesforce, a managed package installed from the AppExchange that reads from and writes to your Salesforce objects without a separate database sitting in between.
| Product | The job it does | Where it fits your process |
|---|---|---|
| Formstack Forms | Captures structured data — fields, validation, conditional logic, Save & Resume, Smart Lists, data routing, payment fields and form analytics. | The front door. Everything downstream inherits the quality of what this collects. |
| Forms for Salesforce | The Salesforce-native managed package. Forms read and write Salesforce records directly, support prefill from existing records, and publish inside Experience Cloud. | When your data already lives in Salesforce and you want capture inside the org's own security model. |
| Formstack Documents | Merges record or submission data into templates and outputs finished files — the document-generation product. | The step after capture, when the data has to become a contract, agreement or pack. |
| Formstack Sign | Collects legally binding eSignatures with an audit trail, timestamps and signer metadata. | The step after generation, when the document has to be executed. |
This page is about the capture layer. If the problem you are solving is really Formstack document automation or eSignature routing with Formstack Sign, those are separate products and separate engagements — we deliver both, and we will say so rather than stretch Forms to cover them. Plan entitlements and published limits change; confirm the specifics for your plan against Formstack's own product documentation before designing against them.
These are three different services with three different buyers, and collapsing them into "we do Formstack" loses all three. Twopir Consulting offers all three. Which one you need depends on whether Formstack Forms already does what you want, needs shaping around your process, or has to be extended past its declarative surface.
Standing Formstack Forms up from nothing — including the Salesforce-native package — so the first production form is designed rather than improvised.
Shaping the product around how your team actually works — all inside the declarative surface, so your admins can maintain it after we leave without writing code.
Custom development where the product stops. This extends Formstack rather than reconfiguring it — a different engagement, scoped and estimated separately.
| The requirement | Configuration | Custom development |
|---|---|---|
| Mapping a form to your Salesforce objects | Yes — field mapping is declarative, including custom objects and lookups. | Only when the target record has to be resolved by logic the mapping cannot express. |
| Showing fields based on earlier answers | Yes — conditional logic and section branching cover it. | Not needed. |
| Prefilling a form for a known contact | Yes — prefill from the record, resolved server-side inside Experience Cloud. | When the values come from a system outside Salesforce, or several records have to be merged first. |
| Creating a task or document on submission | Yes — Flow can act on the record the submission creates. | When the trigger depends on state Flow cannot evaluate, or must run in bulk. |
| Embedding a form inside your own interface | Standard placements only, including the Formstack Lightning component. | Yes — a Lightning Web Component hosting the form in your own screen. |
| Deduplicating against existing records | Partly — standard matching handles the common cases. | Yes, when your matching rules are specific to your data or span several objects. |
We name this boundary in the estimate rather than letting you discover it halfway through the build. If your requirement sits on the line, we will tell you which side it falls on before you commit.
The platform capabilities below are Formstack's. What we bring is knowing which one solves a given problem, and what it costs you elsewhere when you use it. The build is quick; the design is where the value sits.
The field set designed against where the data is going, not against the paper form it replaced.
Branching that makes a long form feel short, and progression that survives an interruption.
Where each submission goes, which record it becomes, who is told, and what happens when it matches nothing.
Taking money on a form without inheriting a compliance problem or a monthly reconciliation query.
The obligations that apply to a public or regulated form, handled in the build rather than in a later remediation project.
The standards that stop today's clean build becoming next year's sprawl — and the review loop that catches drop-off.
The Salesforce-native package does not "integrate" with Salesforce in the usual sense — it runs inside it. What still has to be designed is which data moves where, in which direction, under whose permissions, and what the other side is supposed to do when it arrives.
A submission creates or updates Leads, Contacts, Accounts, Cases, Opportunities and custom objects in one pass. The design work is record-type selection, deduplication and what happens when the match is ambiguous.
Submission inKnown values are pushed back out so returning contacts confirm rather than retype. For sensitive data we resolve prefill server-side against the record instead of carrying values in a URL anyone can edit or forward.
Values outPlaced with the Formstack Lightning component, a 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, not for an admin.
Identity knownThe record a submission creates is what triggers the rest: a task with a named owner, an approval, a document, a stage change. We design that hand-off contract rather than leaving it to a notification email.
Work triggeredWhere captured data has to become a contract or agreement, Formstack Documents generates it and Formstack Sign executes it — with the finished file filed back against the record that produced it.
Next stagePayment fields capture the transaction at submission through a PCI-compliant processor, and the reference and status land on the same record — so intake, document and payment share one audit trail.
Reference filedTwo architecture questions decide most of the rest: whether you run Forms for Salesforce natively or standalone Formstack Forms connected in, and where the form is published — because the publishing surface determines what identity the respondent carries and therefore what the form is allowed to know before they start typing. We answer both in discovery. More depth on the Salesforce side sits on our Formstack Salesforce integration page.
Six stages, one continuous engagement. We run discovery before touching a single form field. A focused implementation — core forms, the Salesforce mapping and a routing model — typically runs four to eight weeks. Deep automation, large estates or complex approval logic take longer, and we scope that before work begins rather than after.
We map the process the form serves — who submits, what decision it feeds, who acts next, and what the data has to prove later. Requirements come from that, not from the existing form.
We rank the existing estate by submission volume, not by the list. A small minority of forms usually carry most of the traffic, and a long tail has not been used in a year — that shapes the whole plan.
Native or standalone, publishing surface, the field and validation model, object mapping, the permission model for the running user, and where the process boundary sits between Formstack and Salesforce.
Forms built, logic and prefill configured, routing and approvals set, payments wired, theming applied — plus any custom development, estimated separately and visible in the plan.
Sandbox first. We test the unhappy paths — unmatched routes, declined payments, duplicate records, a submission from a portal user with fewer permissions — because those are what break in production.
A staged production rollout with hands-on admin training and the governance standard written down, then support after go-live — with form analytics reviewed on a cadence so drop-off gets found early.
Not every engagement starts at Stage 01. If you already run Formstack and the problem is a form estate nobody owns, we start with the assessment — see Formstack audit & optimization.
The pattern is the same across sectors: a high-volume intake that feeds a decision, a document or a compliance obligation. What changes is which record it has to become and who is accountable next.
Buyer registrations, listing submissions, offer details and transaction checklists captured straight onto the property or deal record — so the transaction pack is generated from data the team never retyped.
New client and matter intake collected once, validated at entry, and routed to the right team with the conflict-check data already structured — instead of a PDF someone rekeys into the practice system.
Paper intake packets replaced with secure digital forms, with consent evidence and retention configured deliberately and a BAA in place — cutting the staff data-entry time paper packets create.
Long applications made survivable with branching and Save & Resume, with required checks validated before a record can progress and every step carrying a timestamped trail.
Prefilled renewal and data-refresh forms sent to known contacts, so the customer confirms rather than retypes — and the opportunity, not an inbox, records what came back.
Multi-step internal forms with group approval logic for onboarding, leave and policy acknowledgement — tracked and signed off with a named owner at each step rather than a shared inbox.
We do not publish a percentage we cannot trace to an engagement. These are the changes a well-designed Formstack Forms implementation is meant to produce — the size of each depends on your volume, your starting point and how much rework you are absorbing today.
Validation at the point of entry removes the downstream cleanup that a free-text field creates permanently.
A submission that lands as a record with an owner starts the next step immediately, instead of waiting in an inbox for triage.
Shared option lists make answers comparable across forms, which is the difference between a report and a guess.
Branching, prefill and Save & Resume shorten the perceived form, and field-level analytics show exactly where people still stall.
Consent, retention and approval history configured deliberately means the evidence exists before anyone asks for it.
Templates, naming and a retirement rule keep the hundredth form as cheap to run as the first.
We work with growing, mid-market and enterprise organizations that need help with complex CRM implementations, integrations and business system challenges. Formstack Forms is one layer of that work — and it is designed by the same people who own the object model underneath it.
A form is a write interface to your database. We design the field model against where the data is going — the report, the document, the automation — rather than against the paper form it replaces.
Where Formstack's declarative surface ends and custom development begins is visible in the estimate. You find out at scoping, not halfway through the build when the budget is committed.
We implement across the form and document-automation landscape, so we will tell you when Formstack Forms is the wrong fit for a requirement instead of stretching it to protect a recommendation.
Most form work stops at the submission. Ours continues into the record, the Flow, the document and the report — because that is where a capture problem actually shows up.
Naming conventions, template forms, shared lists and a review cadence are deliverables, not advice. Your admins should be able to build the next form correctly without calling us.
A satellite broadband provider running distributor-led sales, KYC compliance and customer deployment across spreadsheets and email threads. Twopir built one Salesforce system — with Formstack carrying the compliance paperwork that the captured data produces.
As a satellite broadband provider expanding across the Asia-Pacific, we needed a CRM system that could support both scale and precision. Twopir Consulting delivered a fully customized Salesforce Sales Cloud solution that streamlined our lead, account, and opportunity workflows.
Distributor sales, KYC compliance and document generation unified on Salesforce with Formstack.
Screen-flow automation validates required contact roles before a document is generated, and updates Account status on Closed Won — the capture-to-document chain this page describes, running in production. More delivery work sits in our Twopir Consulting case studies.
This page covers the commercial engagement. The pages below go deeper on a single part of it — start wherever your problem actually sits.
The full practice across Forms, Documents, Sign and Workflows — and every other engagement type in the suite.
The capture layer in detail: field and validation design, the six form design mistakes that cost the most, and the accessibility discipline behind them.
Where the submission lands: object mapping, prefill, portal publishing and API-safe delivery across the whole Formstack suite.
Once capture is clean, the same data should produce the contract, agreement or pack without anyone retyping it.
Approvals, step logic and exception handling — for when a notification stops being enough and work needs a named owner.
For estates that already exist: rank by volume, fix the top handful properly, retire the dormant tail, consolidate the duplicates.
Formstack Forms is one part of a wider stack. If the CRM underneath it is the real constraint, start at Salesforce consulting and support, or see how the same capture-to-document pattern runs in Salesforce for residential real estate.
Formstack Forms consulting covers the decisions that sit around the build: which process the form serves, what the field and validation model should be, whether to deploy the Salesforce-native package or standalone Formstack, where the form is published, how submissions map to your objects, who is accountable when one arrives, and what governance stops the estate sprawling. Implementation is the build that follows — forms, logic, prefill, routing, payments, permissions, testing and training. Twopir Consulting delivers both, plus custom development where the product's declarative surface ends.
Scope determines timeline. A focused implementation — core forms, the Salesforce field mapping, a routing model and a signature or document hand-off — typically runs four to eight weeks. Engagements that include a large existing estate, deep Salesforce automation, complex approval logic or custom development take longer. We scope delivery against your actual requirements before work begins, and the custom development portion is estimated on its own so you can see it separately.
Both are valid, and the answer usually turns on how much of your data already lives in Salesforce. Forms for Salesforce installs from the AppExchange as a managed package and runs inside your org, so submissions read and write Salesforce records directly under your org's own security model, with no separate platform to log into. Standalone Formstack Forms suits teams whose forms also have to serve systems outside Salesforce. We assess your org, your publishing surfaces and your workflow before recommending a path — it is the first architecture decision, and it constrains most of the ones after it.
Not on its own — and this is worth being precise about, because the two products are often confused. Formstack Forms is the capture layer. Document generation is Formstack Documents, which merges record or submission data into templates and outputs the finished file; execution is Formstack Sign. In practice they are designed together: the form captures the data once, the document is generated from the record it created, and the signed file is filed back against that record. If your requirement is really document automation, we will scope it as a Documents engagement rather than stretch Forms to cover it.
With submission volume, not with the list. In most estates a small minority of forms carry the overwhelming majority of submissions and a long tail has not been used in a year. Rank by volume, fix the top handful properly, retire the dormant tail, and consolidate near-duplicates into single forms with conditional logic. That sequence delivers most of the benefit early and makes the remaining work smaller rather than larger — and it is why an audit is often a better first engagement than a rebuild.
Yes. The company rebranded from Formstack to Intellistack in June 2025, but the products kept the Formstack name — Formstack Forms, Formstack Documents and Formstack Sign, plus the Salesforce-native Forms for Salesforce and Documents for Salesforce. Both names are current: Intellistack is the company, Formstack is the software. Nothing about an existing deployment changes because of the rebrand.
Formstack states support for HIPAA (with a business associate agreement), GDPR, PCI-compliant payment handling and Section 508 accessibility, and the Salesforce-native product operates inside your org's existing security model rather than beside it. That is the platform capability — it is not the same as compliance. A capable platform still produces an inaccessible form if fields are unlabelled and errors are signalled only by colour, and retention nobody configured is still retention nobody configured. We treat this as a build discipline with a named review step, and confirm the controls against the obligations you actually carry before go-live rather than after.
That is the normal arrangement, and it is the one we design for. Everything in a configuration engagement stays inside the declarative surface precisely so your admins can maintain it after we leave. We hand over the naming and folder convention, the template forms, the shared Smart Lists, the routing map and the review cadence — and we train against your estate rather than a demo org. Where custom development is involved, we document the extension points so the boundary between what your team owns and what needs a developer stays visible.
One form, its submission volume and where the data is supposed to end up. That is usually enough to identify the fields that should not exist, the ones creating downstream cleanup, and the routing that is quietly dropping work — before anyone talks about scope.
Form design reviewed by the same team that designs the CRM the data lands in · Salesforce Partner
