Trigger Custom Event When Data Changes Action Is Inconsistent

Need help App Organization
1

Hi Bubblers,

The action trigger custom event when data changes seems to behave inconsistently.

By inconsistently, I mean it triggers sometimes and sometimes it doesn’t.

Our workflow is structured like this:

  1. Make changes to a thing
  2. Trigger custom event when Step 1’s field changes

For context, this is a marketplace app wherein if user adds a product to their cart and that product is already in their cart, it merges the order with the order that is already in the cart - updating the cart order’s quantity field and other fields e.g. subtotal, etc.

Here’s a more detailed explanation of the workflow:

  1. We search for orders with the same details (same product and variation)
  2. If search count is 1, we search for that order and make changes to that thing
  3. We update the order’s quantity field
  4. In the backend, we have a DB trigger to update the order’s subtotal and profit if order’s now’s quantity is not order before’s quantity
  5. Circling back to the frontend workflow, we have “trigger custom event when order’s subtotal changes” action after step 3.

The issue here is that step 5 “trigger custom event when data changes” behaves inconsistently. There are times where it works fine and sometimes where it doesn’t trigger.

The actions in the custom event are simply frontend actions such as hiding loaders, showing confirmations, and resetting states.

Initially, I thought the cause was that the workflows were triggered even if the search wasn’t finished yet — leaving the order parameter empty

Turns out that this isn’t the case since the action that changes the order’s field are being performed and the fields are being updated accordingly.

Another reason I thought about was that the DB trigger that changes the order’s subtotal was already performed before the custom event could even “watch” the order data and by the time that it “watches” the thing, the change has already occurred.

With that in mind, I have tried these workarounds:

  1. Placing the “trigger when order’s subtotal changes” action before the action wherein we update the quantity.
  2. Using “result of step 1” (order) to ensure that the workflows are running synchronously.
  3. Changing the “field to watch” to order’s modified date and profit (these fields are being updated in the same workflow where the subtotal is being updated)

But the issue still persists. The “Trigger custom event when data changes” action still only triggers randomly.

This isn’t due to privacy issues as well since we have already gone through them.

I also tried to manually change the order’s subtotal which SHOULD trigger the custom event but still the same, it triggers sometimes and sometimes it doesn’t.

It would make sense if the behavior was consistent i.e. the custom event won’t trigger at all since we could deduce that there really is something wrong with the workflow but that’s not the case :frowning_face:

I’m pretty sure I’m missing out on something here. I would really appreciate it if you guys could guide me.

1 Like
2

Hi, first let me point out that I’m assuming that “Trigger custom event when data changes” is set to every time and that the order is accessed on the page directly (not in a custom state etc).

Assuming that’s the case, I’d begin with the DB trigger. In your WF steps, #4 should just follow #3 and skip the DB trigger.

But on a more meta level, are you committed to Trigger CE when data changes? It’s a performance sucker and subject to other things you can’t control.

It’s also questionable UX - when I add 4 of product ABC I expect to see a product with 4 quantities in cart or else I may think the add-to-cart didn’t stick - especially when there’s a product and a variation of it, users may lost track of what’s already in their cart.

Either way, why not just change the front-end behavior if item is already in cart? **A simple conditional on the “add to cart” button can change the button to “edit amount” and will call a different API WF then add to car…**That should take care of all these issues.

Side point: Is there any reason why profit needs to be modified before the order is submitted?

1 Like
3

Hi @code-escapee. Greatly appreciate the response.

What do you mean by set to every time? Are you perhaps referring to “Do when condition is true event”?

I’m referring to this action.
image

image

There’s no option to toggle a “run this” field similar to the “Do when condition is true” event

image

Although this would best make sense, I’m afraid this won’t be possible with our app’s logic and privacy rules. I’m using DB triggers since DB triggers override privacy rules and in our app, the profit is not visible to users (buyers in the marketplace).

Plus, calculating the profit takes a few steps, so I figured it would be best to add a loader and hide that loader once the calculation has been finished.

Edit: I also settled with DB Triggers instead of scheduling API WFs (with ignore privacy rules toggled on) since if I remember correctly, you incur WUs every time you schedule an API WF, aside from the DB actions in the backend WF itself.

With our use case wherein the frequency of an order’s quantity being changed is relatively high, I thought it’d be much faster and optimized to use DB Triggers instead (Not sure on this though)

Could you kindly elaborate more on this? Especially on the performance hit and it being subject to other things I can’t control

The process of adding to cart is already good. It’s pretty much similar to any marketplace out there.

  1. If a product is added to cart but there are no similar products in the cart, we create a new cart order
  2. If a product is already in the cart, we simply add the quantity to the active cart order’s quantity

To simplify our issue, I didn’t mention about conditionals, but yeah, we do have conditionals on the add to cart button, 4 actually.

  1. To check if product has variations and coupon
  2. To check if product has variations but without coupon
  3. To check if product doesn’t have variations and with coupon
  4. To check if product doesn’t have variations but without coupon

Collectively, in these 4 workflows with conditionals, there are actions with conditionals in them that would

  1. Merge orders with coupon
  2. Merge orders without coupon
  3. Apply coupon to an existing order
  4. Create a new order

Our issue is “Trigger when Data changes” action is not behaving consistently even if the data has already been updated.

We’re already referencing to a quantity input. This input’s value would then be added to the existing cart order assuming the product is already in their cart.

Here’s a screenshot of our UI:

image
image754×453 17.7 KB

Profit is automatically calculated along with the subtotal of the order. Any changes in the quantity would also update the profit, along with the order’s subtotal.

Regardless of the calculation of the profit, its currently not related to our “Trigger custom event when data changes” issue since the field that this action is watching out for is the subtotal

What’re your thoughts on this @code-escapee?

4

You’re right. Brain fart on my end.

This seems to imply that you are running all these calculations on front-end - otherwise privacy rules won’t be applicable. Any reason you’re not using a API WF?

It’s not the cause of your issue but no reason to run that profit function until checkout. and either way no reason for user to wait for that to be done using loaders.

Bottom line: what event is happening when the subtotal is updated? is it just hiding loader?

5

Nope, we’re pretty much running almost everything in the backend. The only DB change that we do in the frontend is changing the quantity (For merging orders) which is then “watched” by the Trigger custom event when data changes

For products that are not in their cart, we create this order data in the backend.

I may be wrong but here’s what I thought when we initially built this app:

We heavily rely on API WFs though. In fact, majority of our DB changes are API WFs. This is just for this scenario wherein an order’s product quantity will be updated frequently.

You’re right. There’s no need to make our users wait. Thanks for this.

Just frontend actions such as hiding the loader, showing confirmation alert, and resetting states

6

Doesn’t seem like there’s any need for the trigger. button click - show loader - CE that contains API WF - hide loader and confirmation etc.

7

Yeah, I think it’d be better to do it this way. Thanks @code-escapee

Can I ask you more about this though? What part or at what scale will it impact performance severely? What’re these other things that I can’t control?

Would like to know since we have a decent number of loaders in our app.

8

Loaders should not be based on such triggers as they are finicky, as you see, and then they can really ruin the UX. Performance is simply the listener that looking for changes. When you have lots of searches and other things going on adding such a listener can only hurt. (I haven’t investigated or tested it performance-wise compared to other options, but just a feeling I get from how it operates in the front-end).

The things you can’t control are server timeouts, network connections, and failed workflows, plus a bunch of unrelated blockers that may prevent the trigger from working properly. For example, if the input is focussed or using autobind the trigger won’t work. I know those aren’t applicable here but there are others as well, and if you make a change to add one of those here you’ll be scratching your head for hours trying to figure out how such a small change broke the trigger.

9

I did actually make a solution to this whereby instead of using the “do when data changes event”

You could actually pass the subtotal value into my value change trigger element, and it will trigger a workflow whenever the value changes