Salesforce Flow + FormAssembly: How a Form Submission Can Start a Whole Process

If your organization uses Salesforce, you may have noticed you have access to Salesforce Flow. A FormAssembly form can start a Salesforce Flow by creating or updating a Salesforce record that meets the Flow’s entry conditions. The submission becomes the starting signal, and Salesforce takes it from there: creating tasks, routing cases, sending notifications, or even deleting a record.

Our recent webinar, FormAssembly + Salesforce Flow: An Introduction, walked through two live builds that show how the pattern works, plus a pre-launch checklist and a long list of audience questions. Here is what the session covered.

Key Takeaways

• A FormAssembly form triggers a Salesforce Flow indirectly: the Salesforce connector creates or updates a record, and the Flow starts when that record meets its entry conditions.
• Designing the Salesforce Flow first, then building the form and connector to match it, is the fastest way to avoid mismatches.
• The FormAssembly Salesforce connector can’t delete records by design, but a form can flip a “delete” checkbox that a record-triggered Flow acts on after an approval step.
• FormAssembly and Salesforce Flow are complementary: FormAssembly collects clean, approved data from people outside Salesforce, and Salesforce Flow runs the business process.
• Every handoff needs a test, including the cases that should not trigger the Flow.

How does a FormAssembly form trigger a Salesforce Flow?

A FormAssembly form triggers a Salesforce Flow by writing a record to Salesforce that the Flow is listening for. The pattern is the same in every build, whether the form uses the native Salesforce connector or the newer Salesforce Workflow Connector:

1. A respondent submits a FormAssembly form or workflow.
2. A Salesforce connector creates or updates a record.
3. The record meets the entry conditions of a record-triggered Flow.
4. The Salesforce Flow runs.
5. The business process finishes, such as a task, a notification, or a queue assignment.

FormAssembly doesn’t need to know what happens after step 3, and the Flow doesn’t need to handle messy input. Each side stays focused on what it does best.

Stage	Where it lives	What it does
Collect	FormAssembly form	Gathers data with validation, conditional questions, and approvals, with no Salesforce license required for respondents.
Hand off	Salesforce connector	Writes only the fields you choose to a Salesforce record.
Automate	Salesforce Flow	Runs the process across records, queues, and teams your admins manage.

“FormAssembly collects clean, approved data from people who never have to open Salesforce,” said FormAssembly’s product trainer. “Salesforce Flow runs the process once that data lands.”

Why should you design the Salesforce Flow before the form?

Designing the Salesforce Flow before the form matters because a Flow only runs when a record arrives looking exactly the way the Flow expects. Many Flows already exist, built by a Salesforce admin months earlier, so the form and connector have to fit the Flow, not the other way around.

There are four questions you should work through before building anything:

1. What should Salesforce do? Create a task, route a case to a queue, notify a team, update another record, or start an approval.
2. What triggers the Flow? A record being created or updated, or a schedule.
3. What are the entry conditions? A “needs review” checkbox marked true, or only newly created cases with an urgent priority.
4. What must the form send? The values, whether they come from the form, the workflow, or the connector configuration, that satisfy those conditions.

A small mismatch, such as a renamed picklist value, can let a submission succeed while the automation quietly never starts.

How can a form update a Salesforce record to start a Flow?

A form updates a Salesforce record to start a Flow by changing a field that the Flow’s entry conditions watch. The webinar’s first build used a deliberately memorable example: deleting a Salesforce contact from a FormAssembly form.

How does the contact-deletion build work?

The contact-deletion build combines an approval step, a connector, and a record-triggered Flow:

1. A respondent enters just enough details to identify the contact.
2. The request enters a FormAssembly workflow with an approval step, where a manager reviews it without logging in to Salesforce.
3. After approval, the Salesforce connector locates the contact and updates one field: a “delete” checkbox, set from false to true.
4. A record-triggered Flow starts when a contact is updated, checks that the checkbox is true, and deletes the record.

The FormAssembly connector never deletes anything, and that’s intentional. It protects your data from bad actors when a form is public. Only the Flow, with strict entry conditions, performs the deletion, and only after a human approves it. Restricting who can access the form in the first place adds another layer of safety.

What else can an update-triggered Flow do?

An update-triggered Flow can start any process that follows a status change. The session offered three ideas:

• Onboarding: An opportunity moves from pending to approved, and a Flow creates an onboarding case for the implementation team.
• Contracts: An opportunity moves to contract required, and a Flow builds a draft contract from the opportunity’s data.
• Surveys: A case is resolved, and Salesforce sends the contact a satisfaction survey.

How can a form create a Salesforce record to start a Flow?

A form creates a Salesforce record to start a Flow when the connector writes a new record and a record-triggered Flow runs on every creation. The second build shown during the webinar used FormAssembly’s own internal feedback form.

How does the feedback-topic build work?

The feedback-topic build routes unexpected suggestions to the right person automatically:

1. A team member submits feedback via a form and picks a topic to categorize that feedback under. If no topic fits, they choose “Other” and suggest a new one.
2. The form’s native Salesforce connector creates a feedback record, including the suggested topic when “Other” is selected.
3. A record-triggered Flow looks up the feedback topic and checks whether it equals “Other.”
4. If it does, the Flow creates a task asking the right person or team to decide whether a new topic should exist. If not, nothing happens.

Nobody has to read every submission to catch the occasional new idea. The form collects the feedback, and the Flow decides who needs to see it.

What other routing can a created-record Flow do?

A created-record Flow can route work based on what the respondent selects and who they are:

• A case with a request type of “technical” lands in the technical support queue.
• A case with an urgent priority triggers an email to the priority support team.
• A case from a larger customer is assigned to that account’s owner.

It’s the same form and the same Flow, with different outcomes depending on the data.

Should the logic live in a FormAssembly workflow or a Salesforce Flow?

The logic should live in whichever platform best fits your process, and in many cases that means both. The feedback build could have used FormAssembly workflows with conditional steps instead of a Flow. The team chose a Flow because the work involved Salesforce records and backend actions their admins manage.

Choose a FormAssembly workflow when…	Choose a Salesforce Flow when…
You want to see and adjust the whole process in one click-by-click view.	The logic depends on your Salesforce objects, records, and custom data model.
The process includes steps outside Salesforce, such as updating a Google Sheet, collecting a signature, or generating a PDF.	The action should run no matter how the record is created, including manual entry in Salesforce.
Your Salesforce admin would rather not maintain complicated new automation.	The work belongs with backend actions your Salesforce team already controls.

One attendee summed up the split well: FormAssembly is most valuable when you need to get data into or updated in Salesforce from people who aren’t Salesforce users.

What should you test before launching a form that triggers a Salesforce Flow?

Before launching a form that triggers a Salesforce Flow, run one full test from submission to final result, ideally in a Salesforce sandbox. Each piece can look perfect on its own while the problem hides in the handoff. Check these items:

1. Submit the form like a real respondent. If there’s an approval step, test it both ways: approve one submission and reject one. A rejected request should never touch Salesforce.
2. Confirm the connector writes the right record. Check that the correct record type appears exactly once, and that update matching finds the right existing record. Use a made-up contact when testing deletion.
3. Check connector permissions. The Salesforce user behind the connector must be able to see and edit every field the form sends.
4. Inspect what landed in Salesforce. Verify the actual values, such as the topic, the priority, and the delete checkbox, rather than trusting the form.
5. Make sure the Flow is active. A Flow in draft won’t run.
6. Test both sides of the entry conditions. Something that should trigger the Flow, and something that shouldn’t.
7. Plan for later updates. If the Flow starts on an update, find out whether it runs again the next time someone edits the record.
8. Check the outcome and the failure path. Confirm the task, queue, or email is correct, and make sure someone is notified if the Flow fails.

Frequently Asked Questions

Which FormAssembly plan do I need to trigger Salesforce Flows?

Triggering Salesforce Flows requires the Salesforce Connector add-on. With the add-on, you can use the native form connector, and you can use the Salesforce Workflow Connector in workflows. Older accounts may not yet have access to the latest workflow functionality, so reach out to the FormAssembly team if you’re unsure what your plan includes.

Can a FormAssembly form be prefilled with Salesforce data?

A FormAssembly form can be prefilled with Salesforce data through the Salesforce connector. In the webinar, a feedback button on a Salesforce case opened a form with the case, contact, and account details already filled in, so respondents only added the new information. For more on this, see prefill forms.

Does the Salesforce connector work with custom objects?

The Salesforce connector works with custom objects, because it can work with anything available through the Salesforce API that the connected user has permission to view. If the connected user can’t see an object or field, the connector can’t use it either.

How do I limit a Flow to records created by FormAssembly?

You can limit a Flow to FormAssembly-created records by using the “created by” field as an entry condition. If you authenticate the connector with a dedicated Salesforce integration user, every record the connector creates carries that user’s name. Setting the Flow to run only for that user keeps manual entries out, without adding clutter to your page layouts. Any other field, such as a checkbox or hidden field, also works.

Where should approvals happen: FormAssembly or Salesforce?

Approvals can happen in either platform, and neither is wrong. FormAssembly approvals occur before data reaches Salesforce, and approvers don’t need Salesforce access. Salesforce approvals keep the review inside Salesforce but require more Salesforce licenses and access.

Can data move both directions between FormAssembly and Salesforce Flow?

Data can move both ways. FormAssembly sends data to Salesforce, where Flows process it, and FormAssembly can also pull Salesforce data into forms so respondents can review it, update it, and send it back.

Watch the full webinar

The on-demand replay includes live demos and an audience Q&A. Watch it here.