GCM Docs

Appearance

After submission ​

The thirty seconds between a visitor tapping Submit and your welcome team's phone buzzing is where the visitor form earns its keep. A lot happens in that gap, almost all of it invisible to the visitor. This page walks through the chain — what gets written, what gets fired, and how you wire each piece up to your church's actual follow-up flow.

The atomic write ​

When a visitor submits the form, the browser calls one Postgres function — submit_visitor_form — that does everything in a single transaction. Either every row lands successfully or none of them do. This matters because half-written visitor records were the most common pre-launch bug we had to chase: a member row with no photo, or attendance without a member, or a custom field value pointing at nothing.

In one call, the function:

  1. Validates the passcode if one is set (see Passcode protection).
  2. Inserts the member into the members table with the right org ID and a member type of Visitor (looked up from member_types where is_default_visitor = true).
  3. Stores the photo URL on members.photo after the upload to the member-photos storage bucket finishes.
  4. Writes custom field values into member_field_values — one row per filled custom field, plus the built-in wants_visit, wants_prayer, and prayer_request fields.
  5. Assigns the hierarchy unit if the visitor picked a campus or branch (see Hierarchy & attendance).
  6. Inserts the attendance row if the visitor ticked the "I'm here today" toggle.

The function is SECURITY DEFINER, which is how anonymous visitors are able to write to tables that normally require an authenticated session — RLS would otherwise reject them. All the org scoping happens inside the function itself.

Visitor record on the dashboard

The new visitor appears ​

Within a second or two of submit, the new visitor record is visible in three places:

  • Members → All members, with the photo, name, phone, and a member type chip reading Visitor. The "registered today" timestamp is set.
  • Dashboard → New visitors widget, with the photo prominent and the inviter's name underneath if the visitor filled in "Who invited you?"
  • Attendance → Today's services (only if the attendance toggle was on), grouped under whichever meeting they picked.

Everyone with the members.read permission for your org sees the new record. Pastors and shepherds scoped to a specific hierarchy unit only see visitors assigned to that unit.

The workflow trigger ​

The visitor form is one of the most common workflow entry points in GCM. Any workflow with a member created trigger fires automatically when the new record lands. Most churches set up at least one:

  • Welcome message workflow — send a WhatsApp or SMS within five minutes thanking the visitor and giving them next-step information.
  • Shepherd assignment workflow — auto-assign a pastor or follow-up partner based on the visitor's campus, age range, or family status.
  • Sunday morning notification workflow — ping the welcome team's group chat with the visitor's name and photo.

You build these in Workflows. The trigger to look for is Member created, and most churches filter it further with a condition: member_type = visitor. That way the workflow only fires for new visitors, not when a member is created from a CSV import or by a staff member.

If you only want it to fire for visitors who came through the form (not visitors created any other way), filter on date_of_registration = today and the source of the record. The granular conditions are documented under Workflow triggers.

Staff notifications ​

The fastest path from "visitor submitted" to "someone on staff knows" is the messaging module. Two patterns we see most:

WhatsApp group ping ​

Set up a workflow that, on member-created with member-type visitor, sends a templated WhatsApp message to your welcome team's group:

New visitor: {{member.full_names}} ({{member.primary_phone}}) — {{member.unit_name}} campus. Photo: {{member.photo_url}}

Set it as a group send to the WhatsApp chat ID of your welcome team. Pastors get the ping on their phones before the visitor has stood up from their seat.

Email digest ​

If a real-time ping feels too aggressive, run a daily 11pm digest workflow that emails the day's visitors to the welcome lead. Same trigger (member created, type visitor), but instead of firing immediately, the workflow buffers and sends a single email per day.

Both patterns are documented end-to-end in the first-time visitor recipe.

The conversion path ​

A visitor is not a member yet. The line between the two is one your church draws — after one visit? Three? When they go through a foundations class? When a pastor decides? GCM doesn't enforce a rule.

What we recommend:

  • Leave member type as Visitor for everyone who comes in through the form, with no automatic upgrade.
  • Build a returned-visitor workflow that fires when a visitor reaches three attended services. The workflow can ping a shepherd to call them, or surface them on a "ready to convert" dashboard tile.
  • Have shepherds change the member type to Member manually, after a conversation. The change is logged in the data logs so you can audit it later.

This keeps the social step (deciding someone is now part of the church family) in the hands of a human, while the data step (creating the record, tracking attendance, sending welcomes) is fully automated.

Failures and retries ​

The form is offline-tolerant — if the visitor's phone has bad reception, the submission queues locally and retries when the network comes back. If the passcode is wrong, the visitor sees a clear error and gets another chance.

The most common failure is duplicates: the same visitor fills the form twice in a row (their first submit looked stuck so they tapped Submit again). Both submissions go through; you end up with two visitor records for the same person.

To clean those up: open the duplicate visitor's profile, scroll to Merge → pick the canonical record. Custom field values, attendance, and photo all consolidate onto the surviving record. Most churches do this on Monday morning as part of the standard welcome-team review.

Where to go next ​