Formsite Consulting & Implementation Services

A Formsite consultant designs the process the forms serve, not just the forms. That means deciding what each submission should become in your system of record, structuring the form estate so it stays maintainable, building the conditional logic and approval workflows, designing the PDF templates, mapping everything into Salesforce, and testing the paths that are not the happy path. Building a form is the quick part; deciding what it should collect and where the answers belong is the work.

Formsite's Salesforce integration sends form submissions into Salesforce as records. It works with standard and custom objects, a single form can create records in more than one object, and files uploaded on the form can be saved into Salesforce as Files attached to the mapped parent record. Editing a result in Formsite also updates the record it created. The integration requires Salesforce API access, so the org needs a Professional, Enterprise, Unlimited or Developer edition.

Not directly. The integration sends new records and can update records it created, but it cannot retrieve or delete existing Salesforce records. This is the single most important constraint to design around. In practice we solve it one of two ways: pre-populate the form through its launch link so the relevant identifiers travel with the request, or let the submission land as a record and handle the matching and updating downstream in Salesforce with Flow or Apex. Both work well — but they have to be chosen deliberately, at architecture stage.

Yes. Formsite's Results Docs feature turns each submission into a PDF using one of three approaches: a built-in table format, a fillable PDF template you upload and map to form items, or a custom template built in Formsite's own PDF editor using pipe codes to insert answers and image codes to insert uploaded images. Generated PDFs can be attached to notification emails or saved to connected storage such as Google Drive. The quality of the result depends almost entirely on the template work, which is where we spend the time.

They solve different problems and are often complementary. Formsite generates a document from a submission — it is the right choice when the process starts with information you still need to collect from a client, applicant, agent or counterparty, and when that information needs checking or approving on the way through. A Salesforce-native document generation application generates from records that already exist in the CRM, which suits contracts and quotes assembled from a closed opportunity. If your requirement is genuinely the second one, we will say so.

A focused implementation covering one process — a single form set, one or two document templates and a straightforward Salesforce mapping — typically runs four to six weeks including testing and training. A multi-department rollout with several document templates, approval routing across teams and custom Salesforce development takes longer, and the variable is almost never the form building. It is the number of approvals the process needs and how settled your Salesforce data model is when we start.

Yes, and it is a common starting point. The usual pattern is an estate that grew form by form without an owner: near-duplicates, contradictory logic, PDF templates that break on edge cases, and a Salesforce mapping that no longer matches the data model. We start with an assessment that inventories what exists and what each form is actually used for, then rationalize and rebuild against a proper architecture — usually keeping far fewer forms than clients expect.