> For the complete documentation index, see [llms.txt](https://docs.thewalletcrew.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.thewalletcrew.io/guides-enrolment/enrolment/enrolment-form.md).
# Enrolment form
Set up an enrolment form to collect customer data, apply rules, and issue Apple Wallet and Google Wallet passes.
An enrolment form is the web page customers use to join a program and save a pass, for example after scanning a QR code, clicking an email link or tapping a call to action. It collects the required data, applies the brand's rules, captures consents and issues the pass. When a customer submits the form, The Wallet Crew creates a customer profile (equivalent to a loyalty account) and immediately issues the pass. The same form works for new and returning customers: if a customer is already known, the form can identify them early and skip the questions already answered.
Example enrolment form used to collect customer data before pass issuance.
Real-world examples
* A retail brand places a QR code at checkout to enrol customers in loyalty.
* An event organizer uses a short form to issue a membership pass before presales.
* A luxury brand sends an email link after an in-store visit to create a client profile.
* A ticketing solution embeds a form step to capture missing data before issuing a pass.
Forms are created and edited in the admin console, in **Enrollments → Forms**. The **General** tab sets the pass creation flow and languages. The **Advanced** tab holds the YAML configuration. For the YAML keys, such as `signinOptions` and `completeOptions`, see [Customer registration configuration](#customer-registration-configuration).
## Typical flow
An enrolment form sits between the acquisition channel and the pass template. Customers reach it from a QR code, a website call to action, an email, a mobile app or a POS flow. To choose the channel, see [Enrolment guides](/guides-enrolment/overview.md). The exact screens depend on the configuration, but the logic stays the same.
```mermaid
flowchart TD
A[Customer opens the form from a link or QR code] --> B{Identified early?}
B -->|Social sign-in| C[Known customer: profile loaded]
B -->|Email check-in| V[Email challenge link when the check-in policy requires it]
V --> C
B -->|No match or no identification| D[New customer fills the fields]
C --> E[Customer confirms missing fields and consents]
D --> E
E --> F[The Wallet Crew creates or updates the profile]
F --> G[Pass is issued]
G --> H[Customer saves it to Apple Wallet or Google Wallet]
```
Many customers enrol while standing in a store or switching between apps, so keep the form short on mobile.
## Configure the form
An enrolment form combines UX choices and data rules. The goal is to remove friction without lowering data quality.
* **Fields and validation.** Each additional field increases drop-off risk. Add a field only when it drives a clear business outcome, such as an email address or a phone number. Rules such as required fields, `email`, `regex` and `equality` validators, and phone fields protect data quality and reduce support costs later. See [Validation rules](/guides-enrolment/enrolment/enrolment-form/validation-rules.md).
* **Branding and design.** The form should show the brand logo and colors, match the brand voice, and keep the main call to action visible without scrolling. See [Design](/guides-enrolment/enrolment/enrolment-form/design.md).
* **Identification of returning customers.** [Social sign-in](/guides-enrolment/enrolment/enrolment-form/social-sign-in.md) gives a one-tap identification flow on mobile, reduces typos and typically reduces duplicates. Email check-in adds an email-first step that detects existing customers early and, depending on the check-in policy, sends a verification email whose link returns the customer to the form. For its setup, see [Enable email check-in on enrolment forms](/guides-enrolment/enrolment/enrolment-form/enable-email-check-in-on-enrolment-forms.md).
* **Store context.** One form can serve all stores: a [redirect](/guides-enrolment/enrolment/enrolment-form/redirect.md) adds `storeId`, language or campaign source and gives a printable QR code. The `storeId` refers to [Stores](/configure/advanced-configuration/platform/data-and-integrations/stores.md).
## Customer registration configuration
Customer registration captures identity before a pass is issued. Use it when a CRM or POS account must be created or updated first. It supports website enrolment and in-store QR-code registration. Set the options below in the **Advanced** tab of the form.
### Sign-in options (`signinOptions`)
`signinOptions` controls the social sign-in providers shown on the first step of the form. See [Enable a provider on the form](/guides-enrolment/enrolment/enrolment-form/social-sign-in.md#enable-a-provider-on-the-form).
### Complete options (`completeOptions`)
`completeOptions` is an ordered list of actions taken after successful registration. Each action has a `type`.
| Type | What it does |
| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `addToWallet` | Shows Add to Wallet buttons (`showAddToWalletButtons`, default `true`). Supports `autoDownloadPass` (default `false`), an optional post-download `form` and a `barCode`. |
| `redirect` | Redirects to `redirectUri`. It supports Liquid variables, such as `{{['id.y2.customerId']}}`, in the destination URL. |
| `redirectToPassLayout` | Redirects to the [download page](/guides-enrolment/enrolment/download-pages.md) named in `passLayoutName` for immediate pass download. |
| `reset` | Resets the form after `resetDelay` seconds (default 30; `0` shows a reset button without automatic reset). Use this for shared in-store kiosks. |
### Localize form text and consent wording
All customer-facing text on the enrolment form (field labels, instructions, and consent or opt-in copy) is stored in per-tenant localization files. Open them from **Settings → Enrollment → Localization files**.
Most tenants have a `fields` locale file (`locales/fields`). It governs the form field labels and the consent and opt-in text. Edit it inline from the Localization files screen, the same way pass template fields are translated (see [How to translate a template](/configure/advanced-configuration/wallet/template-configuration/how-to-translate-a-template.md)).
Update the wording for every active language configured on the tenant. A change made in one locale file does not propagate to other languages automatically.
## Data quality
Enrolment happens when intent is high, so customers are most likely to give accurate identifiers. Self-enrolment helps because customers know how to write their own data, and mobile auto-complete reduces typing effort and typos on names, emails and phone numbers. A form that is too long or unclear has the opposite effect: drop-off increases and placeholder entries become more common.
## Privacy and consent
Enrolment forms collect personal data and must be treated as production-grade identity surfaces. Self-enrolment strengthens transparency: customers see what data is collected and why, read the consent language in context, and enter information privately, which matters in store.
The Wallet Crew is deployed worldwide. Regional requirements vary by market, industry, and use case. The platform supports structured consent capture designed to align with GDPR (European Union), CCPA (California), and similar regional privacy frameworks. The [Privacy and security](/policies/privacy-and-security.md) section groups the relevant policies. The [Data Processing Agreement model](/policies/privacy-and-security/data-processing-agreement-model.md) provides the formal privacy framework reference. For common operational questions, see the [Data protection FAQ](/policies/privacy-and-security/data-protection-faq.md). The Wallet Crew also offers a DPO service to help brands operationalize privacy requirements and keep consent practices consistent across regions.
Identification is not consent. Marketing consent must stay separate from identification: collect it explicitly and separately, with a visible link to the brand privacy policy next to the consent field, and avoid pre-checked boxes. Write clear consent language that reads well on mobile, collected as an explicit opt-in. A brand administrator can update the wording directly. See [Localize form text and consent wording](#localize-form-text-and-consent-wording).
## FAQ
Is an enrolment form the same thing as a registration form?
In practice, yes. Both terms appear in the docs. "Enrolment form" is the broader term: it covers registration, identification, profile update and pass issuance in one journey. In the admin console, the menu is **Enrollments**.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.thewalletcrew.io/guides-enrolment/enrolment/enrolment-form.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
