Formstack implementation services take a business process from requirements through to a live, supported build on Formstack Forms, Documents, Sign and Workflows. Twopir Consulting runs that delivery end to end — discovery, process and data design, configuration, data migration, integration, user acceptance testing, enablement and hypercare — with a named deliverable at every phase and a handover your team can actually operate.
A Formstack implementation is the work of turning an agreed business process into a configured, integrated and supported build on the Formstack Suite. The configuration itself is rarely the hard part. The work that determines whether the project succeeds is upstream of it: agreeing what the process should be, deciding which Formstack product carries which step, designing the field and data model so the output is reportable, and specifying what happens when a step fails.
A complete implementation covers seven phases — discovery, process and solution design, build and configuration, integration, data migration, validation and launch, and enablement with hypercare. Skipping any of them does not remove the work; it moves it into production, where it costs more.
The one decision to make before anything else. If Salesforce is in scope, decide between Formstack's Salesforce-native packages and its connected cloud products before design starts. The two models differ in where data is stored, how records are created and what governs access, and reversing the choice after go-live means migrating submissions and rebuilding integrations. We treat it as a documented architectural decision — see Formstack Salesforce integration for the full trade-off.
None of these look like failure at the time. They look like progress — which is why they are usually found six months after go-live, by someone trying to make a change.
The paper form had 60 fields, so the digital form has 60 fields. Nobody asked which of them are ever used, which could be derived from a record that already exists, or which only exist because a system retired in 2019 needed them.
The design reflects how leadership believes the process runs. The people who actually run it know about three exceptions that happen weekly. Those exceptions surface in UAT at the worst possible moment, or — worse — after launch.
Historical submissions, in-flight cases and executed documents all need a destination and a retention decision. Left until cutover week, migration becomes the thing that delays launch or, more often, the thing that gets silently dropped.
What happens when the integration is down, the signer never responds, a required field arrives empty, or a submission is a duplicate? If those answers were not specified, the platform will pick one for you and it will not be the one you wanted.
The project team disbands at launch. Six weeks later a field needs renaming and there is no one whose job it is to assess the blast radius. This is how an estate starts drifting on day one rather than year two.
A recorded walkthrough is not a handover. If the internal team cannot add a field, change a merge template or trace a failed integration without opening a ticket, the implementation is not finished — it has just been paused.
A phase is finished when its deliverable is accepted, not when its calendar time is spent. That is the only mechanism we have found that keeps an implementation honest about where it actually is.
Workshops with the people who run the process, not only those who sponsor it. We document the current state including its exceptions, inventory existing forms, templates, integrations and volumes, and establish the constraints — compliance obligations, retention rules, edition and licence limits.
The future-state process first, then the technical design: product allocation across Forms, Documents, Sign and Workflows, the native-versus-connected decision, the field and object model, naming standards, approval routing and exception paths. Signed off before a single form is built.
Forms, conditional logic, document templates, signature routing and workflow steps built in short cycles against the signed design, each ending in a working demo. Configuration is documented as it is built, which is the only time it ever gets documented accurately.
Connections to the CRM and the wider stack, built to an explicit data contract: direction, matching keys, duplicate handling, field-level mapping, retry behaviour and what happens to a payload that cannot be delivered. Error handling is in the first iteration, not a later one.
Historical submissions, in-flight work and executed documents are mapped, cleansed, loaded into a staging environment and reconciled against source counts. Retention and destruction rules are agreed here, in writing, because they are compliance decisions rather than technical ones.
User acceptance testing against real scenarios including the known exceptions, volume and edge-case testing, accessibility review where the form is public-facing, and a documented cutover with a rollback position. Launch is a decision made against criteria, not a date.
Hands-on enablement for the team that will own the build, delivered against your configuration rather than generic material. Hypercare through the first full process cycle, then a documented handover: field dictionary, template inventory, integration contracts, runbooks and the open backlog.
You should be able to stop the engagement at the end of any phase and still hold something of independent value. If a phase cannot produce that, it is not a phase — it is a status meeting.
| Phase | Primary deliverable | Exit criterion | Who from your side |
|---|---|---|---|
| Discovery | Current-state process map, asset inventory and constraints register | Process owners agree the map reflects what actually happens, exceptions included | Process owners and daily operators |
| Process & solution design | Future-state design document: product allocation, data model, routing, naming standard, exception paths | Signed off by the process owner and the platform owner | Sponsor, platform owner, compliance where relevant |
| Build & configuration | Configured forms, templates, signature routing and workflow steps with build documentation | Demo accepted against the signed design at the end of each cycle | Platform owner reviewing each demo |
| Integration | Working integrations plus a written data contract per connection | End-to-end test passes, including the failure path | CRM admin and the owner of each connected system |
| Data migration | Migrated data in a staging environment with a reconciliation report | Record counts and spot checks reconcile against source | Data owner, compliance for retention rules |
| Validation & launch | UAT results, accessibility review where applicable, cutover and rollback plan | Agreed launch criteria met, rollback position confirmed | UAT testers drawn from real users |
| Enablement & hypercare | Enablement sessions, field dictionary, template inventory, runbooks and the open backlog | Your team completes a defined change unaided | The team that will own the build |
| Shape | What it covers | Choose it when | Avoid it when |
|---|---|---|---|
| Single-process build | One process end to end across the products it needs — typically capture, generation and signature — with the integrations that process requires. | You want to prove the model on a real process before committing to a wider programme, or one process is causing disproportionate pain. | Several processes share the same data model and building them separately would create three incompatible designs. |
| Suite rollout | A shared foundation — data model, naming standards, integration contracts, governance — with several processes built on it in sequence. | Formstack is becoming the standard capture and document layer across more than one team. | There is no named platform owner to inherit the governance model afterwards. |
| Salesforce-native build | Implementation on the Salesforce-native packages, where data is collected and stored inside your Salesforce org under its security model. | Salesforce is the definitive system of record and the process rarely needs to serve systems outside it. | The same process must serve several systems of record, or you need capabilities only the cloud products offer. |
Edition and entitlement prerequisites. Some capabilities depend on your Salesforce edition and your Formstack plan. Formstack documents, for example, that Forms for Salesforce requires API access — generally present in Enterprise, Unlimited and the industry clouds, but something to confirm explicitly on Group and Professional editions — and that certain publishing and prefill features depend on capabilities not available in every edition. We verify these in discovery rather than in build week, and you should confirm current entitlements with Formstack and Salesforce for your own contracts.
The future-state process, agreed with the people who run it and documented in a form that survives the project team.
The decisions that are expensive to reverse: deployment model, data model, product allocation and governance.
The configured build itself, delivered in reviewable increments against the signed design.
Connections built to a written contract so a rename upstream produces an alert rather than a silent gap.
Historical and in-flight data moved with a reconciliation you can show to an auditor.
The part that decides whether you own the build a year from now or are still calling us about it.
The honest answer is that configuration time is rarely the constraint. A single process with clean requirements and one integration moves quickly. What extends a timeline is the number of stakeholders who must agree on the future-state process, the condition of the data being migrated, and whether compliance sign-off is needed. We size the engagement after discovery and tell you which of those three is driving your particular duration, because that is the variable you can actually influence.
Four roles, and the second one is the most commonly underestimated. A sponsor who can settle process disputes; process operators who know the real exceptions and can give time to discovery and UAT; a platform owner who will inherit the build and should be present through the build phase rather than at handover; and an administrator for each connected system. Where retention, consent or accessibility obligations apply, we also need compliance input during design rather than during validation.
Yes, and we usually recommend rationalising rather than porting. Migrating a hundred forms faithfully reproduces whatever caused them to multiply. We inventory what exists, identify which are genuinely distinct processes versus variants that could share one form with conditional logic, and migrate the consolidated set. Existing Word and PDF documents become Formstack Documents templates — Formstack supports Word, Fillable PDF, PPTX and Excel templates alongside its own builder, so most source formats have a direct path.
Both, and the choice is made in design rather than assumed. The Salesforce-native packages install from AppExchange and keep data inside your org under Salesforce's security model, which is usually the right answer when Salesforce is the definitive system of record. The cloud products run on Formstack's platform and connect through integrations, which is usually right when the same process must serve several systems or needs capabilities the native packages do not carry. We document the decision with its trade-offs so it can be revisited on evidence later.
Hypercare runs through the first complete process cycle — for a monthly process that means a month, not a fixed two weeks — because the failure cases that matter only appear when the process actually cycles. After that you can take full ownership with the documentation set we hand over, or retain us on a defined cadence for change delivery and review. What we will not do is make the ongoing arrangement a condition of the handover being complete.
Tell us the process, who touches it and what it currently costs in manual effort. We will come back with the phases it needs, what we would need from your team, and an honest view of which part of it is going to be hard.
Delivered by a Salesforce Gold Partner and HubSpot Gold Partner with 250+ platform deployments taken from design through go-live.
