GCM Docs

Appearance

Passcode protection ​

Most churches leave the visitor form fully public — anyone with the URL can fill it in, which is exactly what you want for a form printed on a bulletin or stuck to a QR code at the welcome desk. But every so often a church wants the opposite: a form that's only accessible to people physically present at the service. Passcode protection is for those cases.

This page covers turning the passcode on, choosing a good one, and the trade-offs that come with it.

When to use a passcode ​

The honest answer is: most churches shouldn't. The visitor form has no personal data on it for anyone to steal — it only takes data in, never gives it out. The realistic risk of leaving it public is one or two spam submissions a year, which a five-second profile-delete handles. So before you turn this on, ask whether you actually need it.

The cases where a passcode genuinely helps:

  • You're testing a new field configuration before launching the form publicly, and you want only staff to be able to submit during the test week.
  • You've had repeated spam submissions — bots that found the URL and are filling it with junk. Rare, but it happens. Sometimes it's easier to passcode for a month than to chase down where the URL leaked.
  • You're running a private event — a leadership retreat or invite-only first-visit Sunday — where you want a sign-in form but only attendees should see it.
  • Compliance reasons — some jurisdictions require any data-collection form to be access-controlled. If your local data-protection rules say so, this is your switch.

If none of those fit, skip the passcode and rely on the natural friction of the URL itself.

Passcode toggle

Turning it on ​

Go to Settings → Visitor Form, then in the Access & link card flip the Require password switch to on. A password input field appears underneath.

Type the code you want to use and click Save. There's no length minimum and no complexity rule — it's a friction barrier, not a cryptographic secret. Something like welcome2026 or firstbaptist is fine. Avoid spaces (they get awkward when you read it aloud at the welcome desk) and avoid characters that don't translate well to a phone keyboard.

The passcode is stored in the app_settings table under the key visitor_form_password and is compared case-insensitively by the submission RPC — so WELCOME2026 and welcome2026 both work. Whitespace is trimmed before comparison.

What visitors see ​

When the passcode is on, the public form first shows a code-entry screen instead of the form itself. Visitors type the code, tap Continue, and the form unlocks for the rest of their browser session (stored in sessionStorage).

The "rest of their session" bit matters: if a visitor enters the code, fills out the form, and submits, they don't need the code again to submit a second time from the same browser tab. Closing the tab clears it.

The code-entry screen does not say what church it's for, doesn't expose any branding, and gives the same generic error for a wrong code — so a curious passerby with the URL but no code gets no information about your church.

Choosing a good passcode ​

Three rules of thumb:

  1. Short enough to say aloud from the platform — "the code is welcome twenty twenty-six, all one word." If you can't say it cleanly, change it.
  2. Memorable enough that a greeter doesn't need to look at a card — they should be able to repeat it to ten visitors in a row without re-checking.
  3. Different from anything you use elsewhere — this isn't a password to anything secret, but reusing a code you use for staff Wi-Fi or another shared system is just bad hygiene.

A common pattern: pick a new code at the start of each season (welcome2026spring, welcome2026summer). It limits the leak window — even if the code ends up shared somewhere it shouldn't, it ages out on its own.

Sharing the code with visitors ​

Print it. Say it from the platform during the welcome moment. Put it on a sign at the welcome desk. The point of a passcode isn't that visitors can't see it — it's that they have to be physically present (or have a known communication channel with you) to receive it.

If you want a code that's automatically shared by your church's Wi-Fi splash page, or sent by text to anyone who scans a QR code at the door, you've reinvented the original public form with extra steps. Just leave the passcode off in that case.

Turning it off ​

Flip the Require password switch back to off. The stored password is cleared from app_settings immediately and the form goes fully public the moment you save.

You can also clear the password without disabling — leave the toggle on but save an empty value — but the form treats an empty password the same as no passcode at all, so it's effectively off.

Caveats ​

  • A passcode is not encryption. A determined bot that reads the page source and the network requests will get past it. It's a "stop casual submissions" tool, not a security boundary.
  • Visitors who get the code wrong don't get a friendly retry flow. They see a generic error and have to type it again. If your visitors are older or less tech-savvy, factor that in.
  • The passcode applies to the form route, not the data itself. Once a visitor is past the code, the underlying submission RPC still validates the code on every submit — so a leaked code can't be used to backdoor data in.

Where to go next ​