I have an issue with my signup flow in Bubble and the solutions I’ve tried so far don’t really get me where I want to be, so I’m hoping for your support.
Use case:
In my app, buyers can create an account.
Their email is stored in the User data type as usual.
When someone cancels their subscription/membership, the User with that email remains in the system (for example with a status like “cancelled”).
Later, the same person can come back and “register again” / reactivate their account.
The problem:
When this person signs up again and enters the same email as before in the form, Bubble’s standard “Sign the user up” action stops with the error message “email already in use”. However, I want exactly the opposite:
no error,
no second user with the same email,
but reuse and update the existing profile.
My goal:
I’d like to have a workflow that does the following:
The user enters their email + additional data (e.g. name, address, chosen plan).
The workflow first checks: Is there already a user with this email?
If no:
create a new user normally with “Sign the user up”.
If yes (user already exists, e.g. with status “cancelled”):
do not run “Sign the user up”,
find the existing user record,
overwrite fields with the new input (e.g. new plan, new address, set status back to “active”),
I think there is an action of sign up that has a checkbox to return existing account, this might be an action of create an account for somebody else or something
Once an email has been used, that authentication record exists permanently unless you delete the user entirely. That’s why Bubble throws the "email already in use error
Can you send some screenshots of your workflow, there’s something i want to check
Maybe you can re-think how this works. Here is how most apps work and how I do it.
When a user cancels their subscription. I don’t delete their account, I just let them log in and redirect them to the page where they can update their subscription information so they can subscribe to an account again. So when their account is not active, I make sure to block them from doing the important things but only allow them to re-subscribe.
Does that make sense?
Why make them go through the whole signup process again?
your branch logic is right, the piece thats missing is you cant actually just treat the existing user as logged in, bubble needs a password to log someone in and you dont have the cancelled users old one. so for the returning branch use the built in assign a temp password to a user action, then log the user in with that temp password, then make changes to that user to flip status back to active and write the new plan and address. that logs them straight in without ever knowing the old password. for the new branch, gate sign the user up behind only when search for users by that email count is 0, so it only runs for genuinely new emails. set them as two events with only when conditions (count is 0 vs existing user is cancelled) so they never both fire on one submit. one thing worth locking down, if reactivation triggers off just typing the email, anyone who knows someone elses email could revive their cancelled account and land logged in as them, so put reactivation behind the payment step or an email
Adding to what @fabi said. Instead of a temp password, use “Send magic login link” for the returning user branch. Cleaner and it closes that security hole.
The flow looks like this >>> on submit, search for Users where email = input’s email and status = cancelled. If count is 0, run Sign the user up as normal. If count is 1, skip signup, update the existing record (new plan, address, status back to active), then send a magic login link. They click it and land in the app logged in.
It’s better than a temp password because the link doubles as email verification. Nobody can revive an account by typing someone else’s email, because the link only reaches the real inbox. No need to gate reactivation behind the payment step.
One caveat >>> do the record updates in a backend workflow. The person filling the form isn’t logged in as that user, so privacy rules will block a normal workflow from editing it.
Also agree with @J805 that if cancelled users can still log in normally, a login page plus a resubscribe screen is simpler than all of this.
