Any suggestions for "discarding" unwanted records instead of going to queue?

How To
1

Hi everyone. Brand new here and have spent the past couple of weeks configuring a scenario that I originally expected to be mostly “plug-and-play” based on advertising but quickly learned I needed to dust off my long-retired developer skills and dive into the deep end (the QuickBooks sales receipt module having a number of un- or mis-mapped fields didn’t help).

Anyway, I’m using an off-the-shelf Make trigger module to monitor order status changes in our ecommerce store.

First I have to contend with the fact that the webhook triggers on all order status changes even though I only want want to work with records that have changed to a specific status (shipped) so they aren’t processed through the scenario to QB until they are final and complete. (Most orders go through 2-3 status changes before actually being shipped.)

There is no alternate webhook available that is status-specific so I have to accept it will trigger multiple times for every order which is fine until it’s not.

I have a filter after the module that only allows orders with a shipped status number to be processed by the scenario, but that doesn’t stop records with all of the other unwanted order statuses from clogging up the queue.

Instinctively I would have expected to have a router that either allows the record to continue on through the scenario, or simply discards it pending future status changes until eventually it is in shipped status and can be posted, but apparently it’s not that simple…

My question is if there is an easy way to “discard” a record that’s just been created via webhook and is still “in” the scenario but doesn’t meet the requirements for further processing? I haven’t been able to find anything built-in to accomplish this (likely because it doesn’t exist).

I realize that I could create an entire router branch, sub-scenario or standalone scenario to go through all the records in the queue one-by-one and figure out which ones to delete and which ones to keep, but that seems rather clunky and operation-inefficient. I also don’t want to just delete everything in the queue since records with the correct status code will not trigger the webhook again unless we manually change statuses back and forth which is not a practical solution.

Curious to hear any thoughts and suggestions, especially if I’m being naïve or unreasonable to think that there should be a built-in way to discard individual records that are active in a scenario in real time. Thanks!

2

You’re not being unreasonable at all—this is a very common situation in Make (formerly Integromat), especially when dealing with webhook triggers that fire too often. Here’s a short and reliable answer to your issue:

:white_check_mark: Best Practice: Use a Filter Right After the Webhook

You’re already doing this, which is great. The key is to place a filter immediately after the webhook trigger to stop unwanted records from flowing into the rest of the scenario.

But here’s the trick:

:white_check_mark: Use a “Set Variable” or “Set Value” module as a dead-end

Since Make doesn’t have a built-in “discard” or “exit” module, use a harmless module (like Set Variable, Set Value, or Sleep) as a discard path to satisfy Make’s requirement for a valid branch:

  1. Router → Two branches:

    • Branch 1: Filter for status == shipped → continue processing.
    • Branch 2: Filter for all other statuses → “Set Variable” → do nothing.

This lets the scenario complete cleanly without queue buildup or errors.

:white_check_mark: Optional: Add Scheduling/Buffering

If the queue still builds up due to volume, consider:

  • Adding a delay before processing (e.g., wait X mins after status update).
  • Batching orders using an iterator and filtering inside a sub-scenario.

:prohibited: Don’t try to delete or clean queue manually

As you said, Make doesn’t let you “reject” a webhook payload; it has to be processed and ended gracefully. The discard branch technique is the cleanest solution available.

:brain: TL;DR:

Use a router with filters and send unwanted records to a dummy module (like Set Variable). This effectively discards them without queue clogging or extra scenarios.

Let me know if you’d like a quick screenshot-style diagram or sample Make scenario structure.

3 Likes
3

Brilliant!

Worked like a charm, thank you very much for your help!

1 Like