@zerocodelogic thanks heaps for replying.
In fact when the mobile users hits the button, the jobcard_exit_report_finalised does update from no to yes. I’ve looked at hundreds of examples of this happening. The backend workflow just doesn’t tigger.
I do take your point about sheduling a backend workflow directly from the mobile app though.
Cheers
If the field is definitely flipping from no → yes from the mobile button, but your “A jobcards is modified” backend trigger still doesn’t run, you’ve basically hit one of Bubble’s annoying edge cases: DB triggers are not a reliable way to “chain” more backend work, especially on Live. One of the replies in that thread nails it — DB triggers don’t always fire other triggers, so using a DB trigger as the “next step” in a chain can randomly fail even though the data changed. Bubble
The most workable fix is to stop depending on that DB trigger for the next steps. Instead, when the user taps the mobile button (the moment you know the change happened), immediately Schedule a backend workflow yourself and pass the Jobcard (or its unique id). In that backend workflow, re-load the Jobcard, verify jobcard_exit_report_finalised is yes, then run your email/schedule-on-list steps there. This makes the whole flow deterministic because you’re not “waiting” for a DB trigger to wake up.
Also add a simple “run once” protection so you don’t double-send emails if multiple users/actions hit it (e.g., a field like exit_report_processed = yes or exit_report_processed_date and only continue when it’s empty/no, then set it as the first step in the backend workflow).
This approach is the same direction you already mentioned (“scheduling a backend workflow directly from the mobile app”) — in practice, it’s the clean solution that works consistently on Live.
