Hello community! 
First time here, and I have a problem I can’t fully solve for my use case. I’ve reviewed and implemented various best practices from this forum and the internet, but I can’t seem to connect everything into a working solution. So, I’m asking for your help.
What is it about?
I have a web app that provides a classic order process (without the hassle of building that part), with some quirks happening behind the scenes after a successful checkout. After submitting the order, among other things (again, without the hassle of building those parts), two user accounts must be created in the system for two different users. Their real emails are obtained during the order process, and I successfully managed to create those two accounts with their provided emails using the “Assign a temp password to a user” action in the backend workflow.
With these respective user accounts created in the system (inside the built-in “User” table), the two users can access a specific part of the website. Let’s call it a portal, which has several functionalities for users. Access to the portal is part of the services I offer as part of the order. Everything works great up to a certain point, but it’s important to note that access to the portal is always restricted to the created accounts linked to a specific order. Only the “Account 1” and “Account 2” associated with a given order can access the portal. The users receive their credentials via email, including login credentials (email, random password, and a custom URL used as the portal access point). Logging into those accounts with the built-in Bubble “Log in” action and “Navigate to portal” action works just fine when built into the frontend workflow.
Issue 1
One or both users tied to a single order can also appear in other orders, meaning they may use the same email for multiple orders. This brings the first problem: in Bubble, you cannot store more than one account with the same email in the “User” table (built-in “email” field). While this limitation is understandable to some extent, I worked around it by adding a new field in the User table to store the user’s real email. In the built-in “email” field, I store a “fake email” (never shown to users and used only for system operations like logging in). So far, this approach works when implemented in the frontend workflow.
However, I want to create those two new accounts (with a “fake email” and a temporary password) entirely in the backend workflow, and here’s where the real issue arises.
To generate the “fake email,” I use a random string before our domain name. This works fine in the frontend, but it doesn’t seem to work in the backend workflow. (See Screenshot 1: the string doesn’t generate, and I cannot append a fixed domain name to the end of the dynamic expression in the “email” input of the signup action.)
My Question for Issue 1
Is it safe to generate the “fake email” in the frontend workflow (using the “Schedule API Workflow” action) and pass it to the backend workflow to handle the rest of the process? When I test this approach, it seems to work — the signup process successfully creates new user accounts even if there are duplicate real emails across different orders.
Issue 2
This is where I’m really stuck. I don’t know how to handle the login process (with all necessary checks, like “Is the user active?”, “Does the user exist?”, “Is the user tied to a specific order?”, etc.) from the backend workflow and then navigate the logged in user to the portal . Ideally, this should all be part of the same process — let’s call it the login process, with some parts handled on the frontend and others on the backend. The idea is that users will use a custom URL for logging into the user account (this url is sent to them with the email message after order is placed) . This URL will include information about the related order and the corresponding “fake email” (e.g., when the user clicks on log-in button I can extract these two details from the URL parameters). When logging in, the user will also need to enter their real email (from the order submission process) and password (generated during account creation) in the designated fields.
What I’ve Found So Far
When trying to implement the login process, I’ve encountered challenges that I can’t fully resolve. Here’s what I know so far:
-
If I perform the login action in the backend workflow (while also passing all the necessary access data to the backend—either provided by the user or extracted from the URL), I am unable to bring the logged-in user’s state back to the frontend when using the “Schedule API Workflow” to link it with the backend workflow. Why so?
-
On the frontend workflow of login process, at some point I need to have a state indicating that the user has successfully logged in and is currently logged in (so is in the state "current user is logged in). This is essential, because I rely on the logged-in user (Current User) information when navigate to the portal. The portal page requires a logged-in current user and related info to function properly and to ensure access (the idea is to pass this logged-in current user during navigation action with using the “Data to Send” parameter), but like I already pointed out before I am unable to bring the logged-in user back to the frontend when using the “Schedule API Workflow”, and so I am unable to pass it when navigating to the portal.
I would greatly appreciate it if someone could take the time to read through my example and share an idea or even provide an example of a solution for my situation.
Thanks in advance, GapoG