I’m banging my head against the wall on this issue.
We have a backend workflow triggered by employees on a Bubble Mobile App. It updates a field to send an email to the customer
This works perfectly on Main but won’t send the email on Live. I can trigger the email successfully on Live by updating the database field from the backend. Thus i think it’s a permissions thing
Users on a job, using the Mobile App, have to all mark the job done. When they have all marked the job as done, another field is updated to make the job complete. This works fine as stage 5 is triggered.
We use Sendgrid so I can see the email has not been generated automatically. When I change a value in the DB as Bubble Admin it does send. Here’s one that got sent today
Hi @Baloshi69 it only triggers when I update the value in the db. It won’t trigger automatically when the users make job complete, like it does in Main
Can you edit your triger only when condition to first check ,
jobcards_old’s_jobcard_exit_report_finalised is not jobcards_now’s_jobcard_exit_report_finalised …. And jobcards_now’s_jobcard_exit_report_finalised is yes
So it will o lynyriger for jobs who were no and trun to yes … currently it is being triger for every yes it’s sometime even for edits which have nothing to do with this field and maybe its overwhelming the system.
Also give schedule api on list few seconds on interval 3s , and why you have two schedule api on list
Ok just got in the office, I’m in Australia. Seems that although trigger to mark jobcard as finalised actually occurs in db, the event sequence in not triggered
Interesting @senecadatabase . Thanks for that. The process works fine on Main but i’m learning that backend workflows are a completely different beast on Live
This is one of those Bubble cases where everything looks right, but Live behaves very differently from Main, and your instinct is correct — it’s not the email itself.
You’ve already proven the important part: the email does send on Live when you update the field directly from the backend. That tells us Send Email, the API workflow, and SendGrid are all fine. So this isn’t an email problem at all — it’s how the API workflow is being scheduled.
The key issue is “Schedule API workflow on a list.” On Live, this step will simply do nothing if the list resolves to empty. No error, no logs — it just doesn’t run. On Main, Bubble is much more forgiving, which is why it works there.
In your case, the list you’re scheduling on is coming from a long chain: jobcard → site → customer → customer_contact (User)
If any part of that chain isn’t readable due to privacy rules, Bubble treats the list as empty on Live. Since this workflow is triggered by mobile users (not admin), Live privacy rules apply strictly. That’s why Stage 5 still runs — it only touches the jobcard — but the email never schedules.
Your API workflow itself is set up correctly, and “Ignore privacy rules” there doesn’t help if the workflow never gets scheduled in the first place.
Two simple things to do:
Double-check User privacy rules so those customer users are readable when the job is finalised (not just for admins).
Add a quick sanity check: Only when customer_contact:count > 0 on the “Schedule API workflow on a list” step. If this fails on Live, you’ve found the culprit.
Bottom line: this is a Live privacy + empty list issue, not an email or API workflow problem. Fix access to that user list, and the scheduling will start working exactly like it does on Main.
When I edit the jobcard as Admin in backend, the rest of the workflow works perfectly. When the user on Mobile App clicks a button to make the change, nothing happens.
This usually happens because the change made from the mobile app is not actually being saved to the database, so the “A jobcards is modified” event never gets triggered. When you edit the jobcard as an Admin from the backend or Data tab, Bubble updates the thing directly and ignores most restrictions. That’s why the workflow works perfectly in that case.
When a normal user makes the change from the mobile app, Bubble applies privacy rules and permission checks. In many cases, the user does not have permission to modify the jobcard or the specific field jobcard_exit_report_finalised. When this happens, Bubble does not always show an error; it simply does not save the change. Since the field never actually changes, your database trigger condition is never met, and nothing else runs.
Another common issue is that the mobile button is only changing a custom state or an input value instead of making changes to the actual jobcard thing. Visually it may look like something happened, but if there is no “Make changes to a thing → Jobcard” action, then the database is never updated and the trigger will not fire.
The quickest way to confirm what’s happening is to check the Server Logs. Trigger the action from the mobile app and look for privacy errors, authorization issues, or cases where the jobcard is empty or not found. If you don’t see a database change, that confirms the trigger never had a chance to run.
A clean and safe solution is to avoid letting mobile users directly modify sensitive fields. Instead, have the mobile button schedule a backend workflow and pass the jobcard’s unique ID. In that backend workflow, update the jobcard with “Ignore privacy rules” enabled and add your own security checks, such as confirming the user is assigned to that jobcard. This approach keeps permissions tight and ensures the workflow runs consistently in both admin and mobile scenarios.
