How to handle transactions in Bubble

Bubble doesn’t have real database “transactions” like SQL (no BEGIN / COMMIT / ROLLBACK). Instead, you make your operations atomic by controlling when things run and what conditions must be true before a change happens. The safest way is to use backend workflows, check conditions before making changes, and design your workflow so each step depends on the updated result of the previous step.

What a “transaction” means in Bubble

In Bubble, a “transaction” is basically: “Do several data changes in a row, and make sure they don’t conflict or execute out of order.” Since Bubble saves each Make changes to a thing step immediately, you must structure the workflow to prevent partial or inconsistent updates.

• Backend workflows run server-side and process steps sequentially.
• Only when... conditions prevent updates when the data is outdated or invalid.
• Custom events help keep logic grouped and reusable.

How to safely handle “transaction‑like” logic

The core technique is: read the most current version of the record at the moment of update, and verify conditions before saving.

• Use a backend workflow and pass the Thing’s unique ID as a parameter.
• First step: Search for the record by its ID and check any conditions.
• Next steps: update the same record, relying on Bubble’s ordered execution.

// Backend workflow: "adjust_balance"
// Parameter: user_id (text)

Step 1: Find User  
Do a search for User:firstitem  
Constraint: unique_id = user_id  

Only when: This User's balance >= amount_to_subtract // prevents invalid update

Step 2: Make changes to User  
Change: balance = This User's balance - amount_to_subtract

When handling payments (Stripe, internal credits, etc.)

Always update your internal database after Stripe confirms the event. The safe pattern is:

• Use Stripe webhook → Bubble backend workflow.
• Webhook contains the final truth (payment succeeded or failed).
• Your backend workflow updates the user or order record based on that event.

Common “transaction” patterns that work well

• Reservation or lock flag: Set a field like is\_locked = yes before updating, and release it after.
• Prevent double processing: Add a field like processed = yes and check it in Only when.
• Sequential updates: Put all dependent changes inside a single backend workflow.