The Verify email step asks a customer for their email address in the Messenger, sends a 6-digit code to it and waits for them to type it in. Use it before you show account details or act on someone's behalf, and to bring a visitor's chat together with the contact you already know.
A card asks for their email address. If Gleap already knows it, the card can skip the question and send the code straight away.
A 6-digit code arrives by email.
They type the code into the card. A wrong code shows how many tries are left, and they can ask for a new code after 30 seconds.
When the code is right, the card turns into a short confirmation and the workflow takes the Verified path. After the last wrong try, or when the code expires, it takes the Not verified path.
Open a workflow that runs on conversations in the Messenger, or create one.
Click Add step and choose Verify email (category Customer interaction).
Write the Message the card shows above the field, for example "Please confirm your email so we can look up your account."
Choose what happens next on both paths: Verified and Not verified.
Setting | What it does |
|---|---|
Use the email we already have | Sends the code to the email on file and skips the question. Without an email on file, the card asks for one. |
Continue as the matching contact | When a known contact has this email, the conversation moves to that contact and the visitor continues as them, with their earlier conversations. On by default. |
Tries | How many wrong codes are allowed before the Not verified path. Default 3. |
Code valid for | How long a code works. Default 10 minutes. |
The card only exists in the Messenger. On email, WhatsApp and other channels the step takes the Not verified path straight away, so put a fallback there.
With Continue as the matching contact on, Gleap looks for a contact with the confirmed email:
A user whose email is proven, because your server sent it (for example with POST /admin/identify) or your app's login signed it. The conversation moves to that user, and the visitor sees their earlier conversations.
Otherwise, a single contact that only has this email, for example from an email to your support address.
Nobody else. A user whose email only came from your app without proof is never a target, because anyone could have typed that email into their own account. In that case the visitor keeps their own contact, which now has a confirmed email.
If the visitor is already logged in to your app, they stay themselves: contacts without a user ID that have the confirmed email join them instead.
The contact's Email verified attribute is true from then on, as long as their email stays the same. Use it in a Condition step, for example to give account answers only to verified contacts. Your server and signed logins set it too.
