We’re launching a new feature that will provide you with more control over the email confirmation flow for your users! Previously, to confirm your end users’ emails, you were required to send those users an email. We are now allowing you to confirm users’ emails without having to send them an email. This could be useful for verifying the email for users that have already been created without sending an email, or it could be used for verifying users’ emails using a non-SendGrid third-party email provider. Here’s how you would do so.
When using the “Send confirmation email” action, simply enter the page you’d like to designate as the confirmation page and check the box for “Just make token, don’t send email.”
You can use this token in future workflow actions as Result of step [#] (Send confirmation email ...).
This token will then verify the current user’s email when they navigate to [app_url]/[confirmation_page]?confirmation_email=[token] where
[app_url] is the Bubble app’s URL
[confirmation_page] uses the page specified in the “Confirmation page” argument
[token] is the email confirmation token associated with the current user’s email
To navigate the end user to this link, you can
Build this URL by creating the expression: [app_url]/[confirmation_page]?confirmation_email= as static data and then add in the token as dynamic data at the end of this URL
Use Bubble’s native page navigation action (“Go to page”), with the destination as your confirmation page and a parameter that uses confirmation_email as the key name and the token as its value
Similar to how the password reset token is generated, the token can only be generated on a backend workflow (the server), not a page workflow, because we do not share the token with the client. However, you can retrieve the token on page workflows by retrieving or saving the response from the backend workflow generating the token.
If the current user does not have an email, a token cannot be generated.
Hope you enjoy using this new feature, and let us know if you have any feedback!
Hi @grace.hong, thanks for this. I understand this enables the Bubble dev to generate a token without the system automatically sending an email.
However, I’m a bit confused by the following…
How can a user’s email address be verified without them responding to a message sent to them via…well…email?
Or do you simply mean that the auto-generated system email message won’t be sent if the token-only option is enabled, thereby enabling the Bubble dev to send a custom email containing the confirmation link. I mean, an email with the confirmation link still has to be sent, right?
If that’s the case, then perhaps a better title for this topic would be, “Can now send custom email verification messages” (or some such).
By checking this option, you can confirm a user’s email without sending them an email - the end user simply needs to navigate to the confirmation URL with the correct token. Note that this is why we generate the token on the server side and by default don’t return the token from the workflow endpoint – that way, we can protect users against any individual verifying an end user’s email.
Nonetheless, in practice, you probably are verifying the user’s email via email, and in that sense, you’re correct that this new feature allows you to verify users’ emails without sending them the default confirmation email from this action. Here’s an example – let’s say you have the user participate in some onboarding flow where they sign up and receive a sign up email. Since they’ve already signed up and they’re receiving the email at that address, you want to verify their email in one go, rather than send another email to verify their email. In this instance, you can create an email confirmation link using this email confirmation token and include that link in the sign up email.
Thanks. Got it. So the Bubble dev now simply has control over when the confirmation email is sent and its content, which means the confirmation link can be in an email such as a welcome message.
(It’s the wording I quoted that I found a bit confusing, as it seems to suggest the user’s email can be confirmed without sending them an email, which would be…well…magic I guess.)
We have shaped out a project on natively enabling SendGrid’s dynamic email templates! It may be a bit before we’ll be able to execute on that project, given other priorities, but it’s on our mind. In the meantime, to leverage dynamic replacement of variables using SendGrid dynamic templates, I’d recommend connecting to SendGrid via our API Connector.
Is there a reason you want to stick with sendgrid over something like postmark?
There are a significant number of bubble users (myself included) who find sendgrid insufficient. Maybe 15% of my user-base cannot receive sendgrid emails because they are blacklisted by so many email servers. Meanwhile 100% of my postmark emails go through.
This is ultimately what has happened (forced to use the API) and with the new ability above it looks like we may never need to return to ‘the easy’ way.
Hopefully it will see the light of day for future builders!
Postmark is very strict on who they allow on their platform, which is why they have a good delivery rate. They wouldn’t be an out of the box solution like Sendgrid on Bubble because they wouldn’t approve majority of Bubble users out of the box. Each account is manually verified which can sometimes take days. They also turn away some accounts saying it’s not a good fit.
But in saying that, it’s high time Bubble sorts out the email non-delivery issue.
Hi @grace.wong, thanks for this useful article.
This is exactly what I’m trying to achieve: send a custom SendGrid email with our design to verify the client email when he signs up.
I’m using the “send confirmation email” token activity & then a “SendGrid - Email (custom)” activity to pass the dynamic verification link to SendGrid but I’m not able to test it on a simple test page with a button.
This is what I’m putting in the custom data of my “SendGrid - Email (custom)” activity:
{ “email_confirmation_link”:“Website home URLconfirmation-page?confirmation_email=Result of step 1 (Send confirmation…)” }
So what happens when you visit that page (with the generated token - i.e. query string param - of course)? I don’t think I quite understand the purpose of test_gabriel page.
I created the page test_gabriel just to test the email verification process when signing up.
I prefer to test the process in a separate page instead of “breaking” the standard email verification process for the login.
That’s weird, now it works when I enter an email in the page test_gabriel & click on Verify Email, now I receive an email with a verification link that redirect to confirmation-page when clicked
I’m still a bit fuzzy on exactly what you’re trying to accomplish, but in a production setup, if you don’t send the email verification link (created using the generated token) to the user via email, then you’re not actually verifying their email address.
Perhaps you already realize this, but the whole point of the email confirmation process is for the user to prove they have access to the email account associated with the email address they used when signing up.
the idea is totally that: during the sign-up process when the user provides his/her email, we send him/her an email with a verification link (created using the generated token) to verify that he/she is the owner of the email before giving access to our platform.
Then he/she clicks the link to arrive to the confirmation-page to confirm the email & only then confirm the user & give access to our platform.
Am I correct here?
