What are Back-end Triggers?

At the time of writing this, Back-end Triggers are still a relatively new addition to Bubble, and just like Option Sets, they haven’t made that big of a fuzz. From what I’ve seen, people are aware they’re there, but somehow it hasn’t registered just how powerful they are. 

There are reasons for this. Biggest among them is probably the list of caveats for when they will trigger and when they will not. I for one was somewhat skeptical at first about using them. I was concerned that they would lull you into a false sense of security about maintaining the integrity of your database, when in reality they would fail to trigger in a wide variety of different scenarios. While that’s true to some extent, my worries turned out to be exaggerated. 

I’ve also heard a number of times, even from seasoned developers, that they’re unreliable. They’re not. You simply need to know their limitations. Bubble’s documentation as of now is not lacking, but a bit difficult to wrap your head around, so we’ll dig into the specifics here. 

But first, let’s discuss something more fun: why they’re so awesome. 

What are Back-end Triggers? 

Back-end Triggers are a way to run a workflow whenever a specific change happens in your database. You create a Trigger in the back-end, and set a condition that specifies what Data Type you want to watch, and the condition for when the Trigger should fire. 

This gives you a “set and forget” way to make sure that any specific database changes you make (even when made in the Bubble database editor) will trigger the correct workflow and maintain your system in whichever way you need. 

Thing before change and Thing now

A powerful feature of Back-end Triggers is that they let you time travel and reference not only the Thing that has changed, but also the Thing as it was before the change was made. Let’s explore that with an example: 

Let’s say you have a note-taking application. For every change made to the note, you want to create a Thing called Undo, that maintains a history of the different versions of the note, so that you can roll back changes later if needed. As you can see in the illustration above, you can access both versions of the updated note: both the content as it was before it was edited, and the new one.

Both versions are accessible throughout the workflow, making it easy to Create a new Undo with the Content value from the Note before Change.

Why are Back-end Triggers awesome?

They can make your app more performance-friendly

Every workplace and action you add to your page makes Bubble a slight bit more sluggish. Back-end Triggers let you move parts of that into the back-end, where the processing is unnoticeable to your users.

They ensure database consistency

Keeping Data Types up to date with changes to each other can be challenging. It can require repeating a lot of workflows in places around your app and if you change something directly in the Bubble database editor (which, let’s face it, we all do sometimes), the associated workflow will not trigger.

Backend workflows ensure that any workflows needed upon change of data are consistently and predictably triggered.

They can save you time as you build your app

Building a trigger and workflow only once, instead of having to remember to keep data up to date in several places saves you time while building. If you set consistent rules for yourself for what kind of data is updated by triggers, you’ll know where to find the right trigger in the backend.

They can make your app more secure

Whatever happens on a page in your app is visible to any users who look for it. Your actions and conditions are not as secret as you may think. Whatever happens in the backend, on the other hand, is invisible to your users. Back-end Triggers can be used to launch operations that you prefer to keep more private.

When will a Back-end Trigger fire and not?

The table below describes different scenarios where a Back-end Trigger will fire or not:

Practical guidelines for using Back-end Triggers

Privacy Rules

Back-end triggers do not adhere to Privacy Rules, and thus have full administrative privileges to the Data Types you’re working on throughout the whole workflow.

Learn the caveats and set rules

Backend Triggers can give you peace of mind or headaches, depending on how well you know how they work. The reason is simple: if you have to worry about it firing when needed or not, it’s no longer helpful, but a concern. Set some rules for when to use them and when not to, based on the table above.

Be careful with Trigger condition complexity

Be mindful of what kind of condition you place on a trigger, and remember that Bubble will need to check that condition every single time a Thing of that Data Type is changed. If the condition itself is complex and demands a lot from the server’s capacity, you can easily spend all the resources you have constantly checking that condition. Keep this in mind as you think about scaling: it may not be a problem with one user in the system, but when you reach a hundred users it may slow your app down.

Don’t place the actions in the Trigger itself

A change made to a Thing by a Trigger will not trigger another Trigger. Now say that five times quickly. This may not be a problem when you set the Trigger up, but as the smart developer you are, you know that you should build keeping future needs in mind.

Instead of placing the actions directly inside of the Trigger workflow, have that workflow schedule a Back-end Workflow where the changes are actually made. Why? Because that workflow will trigger other Triggers. You may not need it to now, but at some time in the future a data change needs to execute something else. As long as you stick to this rule, you’ll have peace of mind that it will.

Consider marking workflows and fields affected by Back-end Triggers

One of the things that held me back from using Back-end Triggers in the beginning was the feeling that they’re a “black hole”. Let me explain.

One of the great things about Bubble is how incredibly consistent it is with being transparent and automating change. If you don’t have programming or database experience, you may not have given it any thought, but the fact that you can rename workflows, Data Types and field names without causing any issues in your app whatsoever is incredibly useful and gives oldskool coders the feeling of having their minds blown.

Backend Triggers demand a bit more of you as a developer. Whether a workflow action will fire off a Back-end Trigger is not communicated in any way, and simply something you’ll have to keep track off yourself. If you’re more than one person working on a project, or you’re handing over the project to someone else, keeping track of updates made by Back-end Triggers can be challenging: the only way to do it is to go through every Trigger and check what it does and when it does it.

Marking your workflows clearly to indicate that they will fire a Back-end Trigger is one way to keep track of how one change in your front-end leads to cascading changes in the back-end.

Back-end Trigger FAQ