Visitor form

The visitor form is the one page in GCM you'll share more than any other. It lives at a public URL — usually printed on the back of your bulletin, on a QR-coded card at the welcome desk, or linked from your church website — and lets a first-time guest enter their own details from a phone in about ninety seconds.

Everything that gets submitted lands in your Members list with member type Visitor. From there, your follow-up flow takes over — workflows can text a welcome message, assign a follow-up shepherd, queue the visitor for next Sunday's check-in, or do all three.

Why this exists as a module

The "self-serve" registration pattern matters because the old workflow — a clipboard, a paper card, and a volunteer typing names into the database on Monday — leaks visitors. Cards get lost. Handwriting is unreadable. Tuesday turns into Friday, the lead goes cold, and the second visit never happens.

The visitor form removes the typing step entirely. The visitor's phone is the data-entry device. They snap a selfie, fill seven fields, tap submit — by the time they sit back down, the record exists in GCM and (if you've set it up) a "thanks for visiting" WhatsApp has already left.

What you can configure

Open Settings → Visitor Form to access this page. You'll find two cards:

1. Access & link — turns the form on or off behind a password, shows the shareable URL, copies it to your clipboard.
2. Form fields — controls which fields appear, what order they appear in, what they're called, which steps they belong to, and whether they're required.

You don't have to touch either card to get a working form. The defaults ask for name, phone, email, photo, and the basics — that's enough for most churches starting out. Customize when you outgrow the defaults.

The data path

Visitor's phone  →  /visitor (public page)
                      │
                      ▼
                 submit_visitor_form RPC
                      │
       ┌──────────────┼──────────────┬─────────────────┐
       ▼              ▼              ▼                 ▼
   members table  attendances   custom field      org_unit
   (visitor)      (if marked)   values            assignment
                      │
                      ▼
              trigger_workflow_member_created
                      │
                      ▼
              workflows fire — welcome SMS, etc.

Because the form is anonymous, all writes go through a SECURITY DEFINER Postgres function (submit_visitor_form). RLS would otherwise reject anonymous inserts. The function runs server-side, validates the org passcode if one is set, and inserts the related rows atomically — either the member, the photo, the attendance row, and the unit assignment all land, or none of them do.

Where visitors show up

After a visitor submits, they appear in three places immediately:

• Members → All members, with member type Visitor and a "registered today" timestamp.
• Attendance → Today's services, if they ticked the attendance checkbox (the form auto-suggests the Sunday service if they're filling it out on a Sunday).
• Dashboard → New visitors widget, with their photo and the name of the inviter (if they typed one in the "Who invited you?" field).

The "graduate from visitor to member" step is manual — your shepherds decide, in their own time, when someone has crossed the line into being a member. Change the member type on the profile, or trigger it from an attendance milestone workflow.

Where to go next

1. Enabling the form & sharing the link — get the URL into visitors' hands.
2. Customizing fields shown — pick what you ask for and where.
3. Passcode protection — when you want to lock the form to onsite use only.
4. Hierarchy assignment & attendance — routing visitors to the right campus or small group.
5. Custom fields & photo — beyond the built-in fields.
6. What happens after submission — workflow triggers, follow-up, conversion to member.