Condition when search items all equal value

Hey there!

I’m trying to set up a workflow with a condition that does a search and returns a list of items that have a field “Status”

I need all the items to have the same “Status” in order for the condition to pass and the workflow to run…but I don’t see that option, am I missing something?

Or do I need to do a count of X items and then do a search with a constraint and get the count and then compare both counts? There has to be an easier way right?


Hi ,

To narrow it down - is this a process that should be fired when the status is of type “completed” - status representing whether the items have been filled out (in other words, the user has completed a form or tasks)?



To be specific, the thing is Order Item and have a Status of Shipped / Not Shipped…so the workflow I need is when All Order Items have the Status Shipped, send an email.


For this operation, we should be using what is refered to in Bubble’s jargon as a "Database trigger event". For official bubble documentation pertaining to these events, please refer to

:spiral_notepad: Why we should be using a database trigger event
In a nutshell, a database trigger event is an event (I will refer to this as a “DBT” from here onwards) that is driven not by the browser - that is, an event originated by a user click event - but by a change in the database. You can think of the DBT as a change in the database that is detected by a pair of ears : they are listening to capture any change in the data that respects the conditions that we are going to configure.

My understanding is that your users create orders, and within each order you have a product list. Each product has a status of shipped / not shipped.

:memo: 1 | Data Structure and Option Sets
I have recreated what I imagine would be the data structure adopted for this, as well as an option set for the status:

:paperclip: 1 | a. Datatype ‘Order’ This type references the product datatype, as a list since a given order will have potentially many products.

:paperclip: 1 | b. Datatype ‘Product’: Each product references back to its order. You will see that while in some cases cross referencing is redundant, in our case it will be necessary to correctly parameter our database trigger event, because we will need to reference the order from a Product datatype starting point later on.

:paperclip: 1 | c. Option set ‘Product status’:

:warning:Front or backend workflows for adding products to orders:

You need to make sure that when your clients create product lists, these products lists are not just created on a standalone mode, each referencing to the order - but that they are also added to their parent Order. In other words, when you look at your orders in your database, you need to see the list of products, as such:

Indeed, the fact that you are referencing each product to its parent’s order does NOT mean that these products are added to the order. It means that if you use a search expression you will be able to output products (by searching for all products that reference a given order).

This adding operation can be configured as a front end workflow or a database trigger. If you need help on this aspect let me know. The rest of this explanation is based on the axiom that your products are added to their parent orders as they are created.

:memo: 2 | Backend configuration

To configure your DBT, you will need to head to your “Backend workflows”.
Capture d’écran 2022-11-22 à 10.38.34

:warning:At this point in time, the backend features are available only in Personal Plan (29$/month) and above.

Here is the path to create a “New Database trigger event”:
Capture d’écran 2022-11-22 à 10.39.32

Now I will try to explain in simple terms why I will be proceeding in the following way, because it may seem a tad backwards at first.

I am going to ask my “pair of ears” to listen for an event, not at the level of the Order datatype, but at the level of the individual Product. This is because my trigger will originate from the fact that a change is made to the status of a given product - a chang to “shipped” - and from there we work our way upwards to see if the order referenced in that product has ALL of its products at status “shipped” or not. The reason for this is that if we ask our pair of ears to listen out for changes at the Order level, it will not detect changes in the referenced product’s respective statuses, as these statuses are in another data type. In other words, when you set up a DBT, the event you are listening for must be directly impacting the datatype you are pointing to, and not impacting a field of a referenced element. Here we are checking for the “status” field of each product, so if our starting point is Orders, you see that we are trying to listen for a field that is underlying to a referenced Datatype. Our DBT will not fire. I learned this the hard way which is why I am insisting on this point, because it can drive one crazy for a while.

So how will we proceed if our starting point is the Product datatype?

(2.a) We first set up our DBT
(2.b) Then, we set up 2 custom workflows, one to send the email, and one to log a confirmation notice within our Order datatype, for testing purposes. We will use two custom workflows here because it will force our backend to fire the confirmation log only AFTER the email expedition has been fired.

2 | a. Setting up our DBT
Here is the setup for our DBT:

This DBT is triggered when the status of a product goes from whatever it was to “shipped”. Our “ears” are therefore listening for all situations where product status switches to “shipped”, at the product data type level.

2 | b. Setting up our custom events: Send email
This is the path to setup a custom event:
Capture d’écran 2022-11-22 à 12.37.40

2 | b. i . ‘Only when condition’

:warning: We will go over the Products and Order number parameters later as they are a secondary subject pertaining to the dynamic contents in the email.

The objective here is to fire the email ONLY if all the products in the order bear the status “Shipped”.

This means that we are looking for ALL the products that share the same Order as the product for which our DBT has detected a status change. Because this custom workflow, as we will see later on, will be triggered by our DBT, we need to search for all products linked to the parent Order of the Product where the change was detected. For this we define the parameter “order”, of type “Order”) (see picture above in the parameter section of the 1. Send email workflow) .This “order” parameter will be defined later in our DBT.

Now under your DBT, as step 1, schedule the custom event we have just configured. As you can see, the DBT is requiring the configuration of the “order” parameter setup for the Send email event. We set this to “Product Now’s Order”.

Capture d’écran 2022-11-22 à 12.54.19

Look back at your Send email custom event to get the full picture:

In the “Search for” expression of the “Only when” condition statement, you see that the “Order = order” definition is saytin, search for products where the referenced order is, applying the DBT parameter definition, the Order referenced by the Product affected by the change.

2 | b. ii . Setting up the email

Looking back again at our DBT’s parameters, you see that we have defined the products and the order number. This will be leveraged when we set up the contents of the email.
Capture d’écran 2022-11-22 à 12.54.19

Click on the Custom event’s “send email” | Step 1 Send email

In the body, select “arbitrary text” that we will define in a message that combines static and dynamic text. I have configured this just to show you how you can leverage our parameters in a way that allows you to insert contextualised data in your email. Feel free to define any other parameters and remember to define them in the DBT as well.

In the arbitrary text you have more arbitrary text:
Capture d’écran 2022-11-22 à 13.34.21

This will list the order’s product in the mail. In order for this list to not be just a list on one line separated by comma, you can use the “join with” function and just type a line break in the following arbitrary text.

2 | c. Setting up our custom events: Email sent log

This event will result in our Order Datatype’s “Email sent” field to be checked to yes once the mail is sent. Because as said before, we define this in a dedicated custom event, the fact that this box is checked ensures that the previous step - send email- has been fired.

2 | c. i. Define your parameters (same as for “Send Email” custom event)

2 | c. ii. Step 1 event: Make changes to thing :

Capture d’écran 2022-11-22 à 13.40.44

Add this custom event to your DBT triggers:
Capture d’écran 2022-11-22 à 13.42.07

2 | c. iii. Test your workflow:
Capture d’écran 2022-11-22 à 13.43.28

I know this is a bit of a handful and seems like a huge load of complexity but once you understand the logic it is easy to implement for other usecases as well. I hope it was clear enough.



This topic was automatically closed after 70 days. New replies are no longer allowed.