Workflow integration β
A form by itself just collects data. To do something with the data β email a pastor when a prayer request lands, text a leader when someone signs up for a small group, create a member record when a baptism interest form is submitted β wire it to a workflow.
Every form submission emits a form.submitted event. Workflows listen for those events and run whatever actions you configure.

The trigger β
The form.submitted trigger is one of about two dozen built-in triggers β see the full list in Triggers. When you pick it, the workflow builder asks you to filter by form.
You can either:
- Specific form β only this workflow fires for that one form. Use this when each form has its own follow-up (a prayer-request form fires the prayer chain workflow; a small-group signup form fires the group-leader notification workflow).
- Any form β fires for every submission across every form. Use this for org-wide policies β "log every form submission to a Slack channel," for instance.
In the workflow builder, the trigger node exposes the full submission payload as {{trigger.data}} β including every field by ID, the submitter name, the submitter email, the form ID, and the submission timestamp.
Common patterns β
1. Email notification to a leader β
The most common pattern. Replaces what the Notification emails field in form settings looks like it does, but actually doesn't.
In the workflow:
- Trigger β
form.submitted, filtered to your form - Action β Send email
- To β hardcoded address(es) of the leader(s)
- Subject β
New {{form.name}} submission - Body β pull the field values you care about from
{{trigger.data}}
You can reference any field by its label, like {{trigger.data.prayer_request}}. If the field label has spaces, use the field ID instead β copy it from the form builder's field-settings panel.
2. SMS notification to a leader β
Same shape as email, just swap the action:
- Trigger β
form.submitted, filtered to the form - Action β Send SMS (requires Messaging module enabled β see SMS)
- To β leader's phone
- Body β short summary:
New prayer request from {{trigger.submitter_name}}. Open GCM to read.
SMS is best for high-urgency forms (prayer chain, crisis hotline) where the leader needs to know now. Keep the body short β SMS is for "go check the dashboard," not for delivering the full submission.
3. Create a member from a form submission β
A form is not a visitor form (that's a separate module β see Visitor form). But you can build a workflow that creates a member record from any form submission.
- Trigger β
form.submitted, filtered to a "Join the church" or "Visitor card" style form - Action β Create member
- Map fields β name from
{{trigger.data.name_field_id}}, email from{{trigger.data.email_field_id}}, etc.
This is the right move when:
- You need a fully custom set of fields (the visitor form has a fixed schema)
- You want the form to go through a manual review step before becoming a member (use a workflow with a "Wait for admin approval" action)
- You're collecting members through a flow that isn't a welcome-desk visit (online seeker form, prayer line follow-up, etc.)
4. Auto-assign to an org unit β
Pair "Create member" with "Assign to org unit" in the same workflow. If your form has a Select field for "Which campus do you attend?", use the selected value to route the new member to the right unit:
- Create member from submission
- Branch on the value of the Campus field
- In each branch, assign to the matching org unit
The visual builder makes this fan-out pattern straightforward β see Multi-step workflows.
5. Send a confirmation to the submitter β
Often you want to acknowledge the submitter, not just notify yourself.
- Trigger β
form.submitted - Action β Send email
- To β
{{trigger.submitter_email}}(the field GCM auto-extracted from the first Email field) - Body β "Thanks for submitting your prayer request. A member of our prayer team will be in touch within 48 hours."
Pair this with a static Success message on the form itself (set in form settings) for a double confirmation β the visitor sees a thank-you immediately on the page, then gets an email a few seconds later.
What the trigger payload looks like β
The shape of the data the workflow receives:
{
"submission_id": "a8...",
"form_id": "b2...",
"form_name": "Prayer Request",
"submitter_name": "Jane Doe",
"submitter_email": "jane@example.com",
"submitter_ip": "203.0.113.42",
"data": {
"field-1-uuid": "Jane Doe",
"field-2-uuid": "jane@example.com",
"field-3-uuid": "Please pray for my mom's surgery on Tuesday",
"field-4-uuid": ["weekday-mornings", "weekend-evenings"]
},
"created_at": "2026-03-15T14:22:33Z"
}The data block is keyed by field ID (UUID). When you reference field values in workflow actions, you can use either the ID directly or the friendly label (the workflow builder resolves labels to IDs for you).
Why notifications-via-workflow instead of the form-settings field? β
The form-settings panel has a Notification emails input. It looks like it does what a workflow does. It doesn't β it stores the addresses, but the actual send is wired through a workflow under the hood.
We surface the field on the form because most churches want at least an email-on-submit and it's the obvious place to look. But the moment you outgrow "send one email to one address" β when you want SMS, conditional routing, different recipients for different field values, or any of the other things workflows do β you need to build a real workflow.
The yellow hint banner in the form-settings panel points this out:
To receive email notifications for submissions, create a workflow with the 'Form Submitted' trigger.
That's the canonical pattern. The notification-emails field is best thought of as a hint, not as the source of truth.
Monitoring runs β
Every workflow that fires from a form submission shows up in Workflows β Runs with the form's name in the trigger column. If something's not working β a leader's not getting the email, a member's not being created β that's where to look.
See Monitoring runs for the full debugging playbook.
