Most teams that live in Salesforce know the drill: open a record, open a form, then copy the same case number, account name, and contact details from one into the other by hand. It is slow, it invites typos, and it scatters good data into places no one can use. Prefilled Salesforce forms close that gap — one button click opens a form already populated with the context your team needs, so the only thing left to do is the actual work.
In a recent FormAssembly webinar, our product training team walked through three real examples of this pattern in action — a support case escalation, a multi-record customer feedback form, and a field operations report — using both the Salesforce Prefill connector and the Salesforce Workflow connector. Here are the five takeaways worth keeping.
1. The value isn’t the button — it’s what happens after the click.
The button is just the trigger. The real win is that the form will open already filled with the right Salesforce data, so your team can skip the gather-and-retype step entirely.
“The real value of this pattern isn’t necessarily that Salesforce button, but it’s really what happens after that click,” one of our trainers explained during the session. The shape stays the same across every use case: the user clicks a button, records are passed, and the form opens ready to go. Once you see that pattern, you can apply it to almost any repeatable process your team runs each week.
2. One click can prefill data from several Salesforce records at once.
A prefilled form is not limited to the single record you launched it from. By following Salesforce relationships, one button can pull data from related objects in the same click.
The webinar’s customer feedback example started from a case record, then used the case’s account ID and contact ID as lookups to prefill account and contact details too. The same form could be launched from an opportunity by a sales rep, an account by a customer success manager, or a case by a support specialist — each person captures feedback in a consistent way from wherever they already work. That consistency pays off later: when every submission follows the same structure, your reporting actually holds together.
3. You can prefill details about the person who clicked the button.
Prefill isn’t only about the record. You can also capture who launched the form — the Salesforce user — and pull their details in automatically.
In the field operations example, a specialist working in the Salesforce mobile app tapped a button on a work order and got a report form that already knew the site, the assigned work order, and the specialist’s own information. No re-entering their name or role on every submission. For any process where it matters who did the work, this turns a tedious form into a near-instant one.
4. Two connectors get you there — pick the one that fits the process.
There are two ways to prefill Salesforce data, and the respondent’s experience is identical either way. The difference is entirely behind the scenes.
The form-native Salesforce Prefill connector handles prefill at the form level and is the quickest path for straightforward, single-form use cases — like the first two examples from the webinar. The Salesforce Workflow connector is built for multi-step workflows, and it both prefills and sends data, so you don’t switch connectors mid-process. The field operations report used the workflow approach to chain lookups together: find the operation, use its park ID to prefill the related park, then pull in the user. Choose the form connector for speed and simplicity, and the workflow connector when the process has multiple steps.
5. Prefilled fields stay flexible — editable, locked, or hidden.
Prefilling a field doesn’t mean freezing it. You decide what respondents can see and change, field by field.
Leave a field editable and a contact can update their own phone number or address on a self-service form. Set a field to “no overwrite” under access control and the prefilled value can’t be changed. Or hide the field entirely — common for ID fields you need to capture but don’t want anyone touching. As one trainer put it, you can “set it to no overwrite or hide it completely,” depending on whether the data is for the respondent or just for your records.
Questions from the webinar
The live Q&A surfaced a few questions that come up again and again. Here are some of the most useful ones.
Can I add these buttons to any Salesforce object, including custom ones?
Yes. You can create a Salesforce button on any object that supports buttons, standard or custom. The webinar’s field operations example used a custom object, while the support and feedback examples used the standard case object.
Can one button update or check in multiple records?
Yes. For something like checking attendees into an off-site event, you can open the event record, click the button as many times as you need to prefill the event details, let each attendee enter their own information, and use a submit connector to update all the related records when each form is submitted.
Can I prefill all the child records of a parent record?
Yes. Pass the parent’s ID into the form and use repeatable fields to prefill the related child records — for example, all open cases tied to a contact. There’s a practical limit of roughly 20–25 records, so for larger sets, add conditions to your lookup (open cases only, for instance) to filter down to what you actually need.
Can I use prefill without buttons, or on a public form?
Yes, with a caveat. The buttons in this session are simple links, so they’re for users inside your Salesforce instance — not external respondents. To reach people outside Salesforce, drop the same prefilled link into a Salesforce email template, so a teammate just clicks “send.” For public self-service prefill, put an authentication step in front of the form, or use a workflow that emails the respondent a prefilled link rather than exposing record data on a guessable lookup. The setup on the FormAssembly side stays the same; the security layer is what changes.
Does prefill work with embedded forms?
Yes, and the publishing method determines what’s possible. An iframe-embedded form supports static prefill — useful for pinning a form to a single campaign. Other publishing methods support dynamic prefill, so a personalized link can carry each respondent’s data into the embedded form. The compare-publishing-options guide spells out which methods support dynamic prefill.
Watch the full webinar
The replay walks through each example end to end — the Salesforce button user experience, the connector setup inside FormAssembly, and the button configuration that ties it all together — plus the full live Q&A. A step-by-step use case doc is also slated to follow.
