Backend API Trigger with Log In Not Working (Email confirmation process)

(Backend API Workflow) I have a Trigger that schedules two API workflows when a user signs up. I have another Trigger that cancels the scheduled APIs when the user confirms their email (Expressed as "User before change’s email confirmed = “no” and User Now’s email confirmed = “yes”. )

If the user is logged in when they click on their email confirmation link, this works great. If however, they are logged out when they click on the email confirmation link, and then they have to log in - it doesn’t work. The Trigger isn’t executed even though the users email confirmation still changes from no to yes.

I can work around it a bit if I add in a duplicate “cancel scheduled APIs” into the workflow of that log in, but I would also need to add it into the edge case of click email confirmation > log in > forgot password and now I would be running a cancel scheduled API everytime someone resets their password, long after this initial email confirmation.

I’m quite new to bubble so I was hoping someone could help me understand why the trigger doesn’t execute in those situations or help show what I’m doing wrong.

Thanks!

Can you share your Setting for the trigger that cancel?
What I think is that you are probably using “Current user” data while you should use a “Do a search for user” probably.
Also, instead of cancels the scheduled API workflow,you can just have filter that will check if the user confirmation is “no” in the Backend workflow

Thank you for your response. Here is an image of the Trigger that “listens” for the change to email confirmed is yes.

It’s three images, two are me highlighting the actual cancel steps (I store the scheduled API id in a field list under the user so I can reference it here for the cancel)

I have the scheduled API workflows set for a time in the future, so I’m not sure if that condition you mentioned still applies?

Thanks again for any insight you can lend.

I understand how you have set thing using Trigger WF. I think you may consider this an issue and submit a ticket to Bubble.
But for what I suggest is to add the filter to Endpoint in red (because I guess they are the two scheduled workflow). Check if the user you want to do something is confirmed or not. If not, let the scheduled WF process.

1 Like

Thanks for the quick response.

Yes those two in red are the scheduled workflows. That’s a great idea. While I would prefer to remove the scheduled processes so they aren’t scheduled to run in the first place, your suggestion is a great “backstop” to make sure they just don’t process the action (depending on the condition).

That may be the route I have to go until/unless I can solve removing the scheduled workflows when they confirm (in those edge case scenarios).

Thank you for your help.

1 Like

I will follow this up in case it may help someone in the future. While I like, and will keep, the idea of using conditions mentioned by @Jici as a fail-safe, I realized another way I could cancel the scheduled APIs when the user’s email is confirmed (besides the database trigger, since it wasn’t working in the aforementioned situations). Since the email confirm link goes to a specific page, I was able to create a workflow on that page that says: When current user’s email confirmation is yes, run this API workflow. I then created an endpoint API workflow that ran the same “cancel scheduled API” processes I had in the API Trigger.

1 Like

Did you resolve this? I am seeing similar odd functionality on my app.

Are you still having trouble? The solution I used is in the last post: Basically use conditions to create the trigger for an Endpoint API Workflow that runs the same processes as the Database Trigger Workflow would run.

Since the Trigger API Workflow wasn’t always being “triggered”, I put that same workflow in an Endpoint API Workflow. I then set up a conditional workflow on the “front end” page to run it. The condition I used was “when user’s email confirmed is yes run this API workflow” and I put it on the email confirmation page (that is the page that the email confirmation link leads to).

Does that help?

No, not seeing this issue anymore. I think it was user error on our end.