Data Store "Search Records" module returns empty output when used after Gmail "Search Emails" module, preventing deduplication

:bullseye: What is your goal?

Prevent processing duplicate emails from the same sender

:thinking: What is the problem & what have you tried?

The problem:
The Search Records module produces empty output when receiving data from Gmail > Search Emails. No Total number of bundles field is available for router filtering.

Specific observations:

  • The Search Records module receives input bundles from Gmail (confirmed by speech bubble showing input data)
  • The module appears to run but produces ‘empty output’ – no Total number of bundles or Key fields are available
  • When I run `Search Records` in isolation (right-click → “Run this module only”), it works correctly and returns the expected output

What I’ve tried:

  1. Verified the data store connection – data store exists and contains records
  2. Checked filter configuration – searching for sender’s email (From Email), mapping appears correct
  3. Added router with Total number of bundles = 0 filter – filter never evaluates because field is missing from output
  4. Tried using Key variable in router filter instead (exists / does not exist) – same issue, field not available
  5. Toggled “Continue execution on empty results” in Advanced Settings – didn’t resolve the issue
  6. Tried Get a record module instead – produced “Missing required parameter ‘key’” error

Note: I’m trying to avoid using the Array Aggregator module as it consumes many credits for large volumes of emails.

:clipboard: Error messages or input/output bundles

Search Records output when running full scenario (empty):

Bundle 1Collection
Input (from Gmail):
  Key: {{1.fromEmail}}
  Filter: From Email = [email protected]

Output:
  (empty – no fields available)

Search Records output when running module alone (working):

Bundle 1Collection
Total number of bundles: 1
Key: [email protected]
dataCollection: [record data]

Router filter attempted (both approaches):

  • Approach 1: Total number of bundles Equal to 0 – field not available
  • Approach 2: Key does not exist – field not available

:camera_with_flash: Screenshots (scenario flow, module settings, errors)

Hey there,

under advanced settings, set it to continue even if it doesnt find anything:

I’ve tried that as well. I even tried to start from scratch and use only the first part of my workflow until the router branches out. Doesn’t work

What about it doesn’t work?

The flow still stops at the first router branch. Maybe someone can simply set it up and tell me if its working for them.

Gmail (search email) - data store (search a record) - router with two branches (one continue with the workflow , the other one stop and do nothing)

I thought it’s pretty straight forward but that seems not to be the case (or at least not for me :wink:

Can you show some screenshots from the execution history? Cause I can guarantee you that setting with checking if the key exists or not is working 100%.

And what are the modules returning as outputs, how were they configured during that specific run, what do the filters look like and what you see when you click om them in that specific run?

Please provide some consistent information so we can see what is going on with the scenario.

Thank you for taking the time to look into this. I appreciate the help. Based on your request, I’ve pulled the specific details from the scenario history for the most recent run with the “Continue the execution of the route even if the module returns no results” setting enabled.
**
Limit:** 3
Content format: full
Filter type: gmailSearch

I’ve attached three screenshots from the History tab of that run:

Screenshot 1: Data Store Advanced Settings (data_store_adv_settings_true.png)
This shows the module inspector for the Data Store > Search Records module. It confirms:

  • Limit: 1

  • Continue the execution of the route even if the module returns no results: true

  • The filter and sort arrays are empty (no filters applied)

Screenshot 2: Filter Inspector (process_email_blocked.png)
This shows the router filter that comes after the Data Store module. It reveals:

  • The filter is checking 181. Key (from the Data Store module, module 181)

  • The filter shows a warning icon (!?) for all three bundles, indicating the condition could not be evaluated**

    Recent Run Configuration & Outputs**

Screenshot 3: Overall view of the history (history_details.png)

1. Module Setup During the Run

I ran the Gmail > Search Emails module with query.

It successfully returned one operation with 3 bundles (emails). The output included fields like Message ID, Thread ID, From (email), Subject, etc. This confirmed the module was working and receiving emails.

2. What the Data Store Module Returned

The Data Store > Search Records module had the “Continue the execution of the route even if the module returns no results” option toggled to Yes (confirmed in Screenshot 1). Its filter was configured to search for the ThreadID in the data store.

When the scenario ran, the Data Store module produced 3 operations (one for each email bundle from Gmail). All three operations had the same output:

Output
Bundle 1Collection
Key ThreadID
dataCollection
Total number of bundles 1
Bundle order position 1**

Key observation:** The Data Store module is returning Total number of bundles: 1 for all three emails, indicating that the ThreadID already exists in the data store for each email. However, the output is showing Key ThreadID as a literal string, not the actual Thread ID value.

3. Router Filters and What I See (From Screenshot 2)

After the Search Records module, I connected a Router to make a decision based on the search result. I tried to set a filter condition where Key exists (or does not exist).

What the Filter Inspector shows:

  • The filter is checking 181. Key (module 181 is the Data Store module)

  • For all three bundles, the filter shows a warning icon (!?) indicating the condition could not be evaluated

  • This means the Key field is not available in the filter, even though the Data Store module output shows Key ThreadID

This is one of those Make traps where the module runs green but returns nothing, so the route just dies quietly. Two separate things are going on.

First, Search Records returns zero bundles when it finds no match, and that empty result stops the route. The “continue even if there are no results” toggle lets it pass through, but it does not give you a “Total number of bundles” field. That field only exists on aggregators and array outputs, not on a per-bundle Data Store search, so routing your dedup on it will never work. That is why both branches behave the same after you flipped the toggle.

Second, the “works when I run it alone but empty in the chain” part is almost always the mapped filter. When you run the module by itself you type a literal value, but in the chain the search key is mapped from the Gmail module. If that mapping resolves to an empty value, or to the whole email object instead of the plain message id string, the search matches nothing and returns empty with no error. Open the Search Records bubble on the failing run and check exactly what value went into the filter.

For the dedup itself, the pattern that holds up: use Data Store, Get a record, with the Gmail message id as the key, turn on continue even if not found, then in the router filter on that key field with Exists for the already-seen branch and Does not exist for the process branch. After you process, Add or replace a record with that message id so the next run sees it. Get a record by key is steadier here than Search with a filter.

If you can share what the filter field resolves to on the failing run, that will confirm whether it is the mapping or the route logic.

Nothing you attached shows anything. Only thing is that it looks like the key did exist in the filter. Please see the screenshots from my scenario:

Thank you for taking the time to look into this. I’ve been testing both approaches based on your suggestions, and I appreciate the detailed diagnosis.

On Search Records

The output from Search Records was already shared in my initial message, but I’ll repost it here for clarity.

When I run Gmail > Search Emails with a limit of 3, I get 3 bundles. The Data Store > Search Records module then produces 3 operations (one per email). The output for all three operations is identical:

Output

The key issue is that Key shows as the literal string ThreadID, not the actual Thread ID value. This is why the router filter can’t evaluate — the field exists, but it contains the field name instead of the data.

On Get a Record

I’ve already tried switching to Get a record. I ran the module first (without the router filter) to “register” the fields, but the Key variable still didn’t appear in the router filter dropdown. Even with “Continue execution” toggled on, the router filter couldn’t see the Key field.

Regarding the Empty Dropdown in Data Store Filter

One thing I noticed is that I didn’t create a Data Structure for my Data Store. This appears to be why the dropdown in the Search Records filter is empty. However, I’m not sure if this is the root cause of the data not flowing, since I’m not setting up a filter in the Data Store module itself — I’m only checking for the existence of the Key in the router.

So you populated the data store with the wrong data. Check the scenario that filled it.

Thank you for all your help on this. I have some good news, I was able to fix the issue and the workflow is now working.

The root cause was that my data store had been populated with incorrect data during earlier test runs. The keys stored in the data store were the literal string "ThreadID" instead of the actual Gmail Thread ID values (like 19ed54ddb1f4683b).

This prevented the Search Records module from finding matches correctly.

I cleared the data store and ran the workflow again. This time, the Add/Replace a Record module correctly saved real Thread ID values. You can see the fix in the screenshot

the output now shows Key: 19ed54ddb1f4683b instead of the literal "ThreadID".
**
What Happened During the Test Run**

During my latest test run, the Gmail > Search Emails module fetched 3 bundles. Here’s what happened with each:

Bundle Thread ID From Result
Bundle 1 19ed54ddb1f4683b John Doe (me) Processed — This was a new Thread ID not in the data store
Bundle 2 19e799065781f778 John Doe (me) Filtered out — This Thread ID already existed in the data store
Bundle 3 19e799065781f778 BIA Acquisition Filtered out — Same Thread ID as Bundle 2, already existed in the data store

**
Why only one was processed:** Bundles 2 and 3 belong to the same email thread (they share Thread ID 19e799065781f778). The first time an email from this thread was processed (in a previous test run), its Thread ID was saved to the data store. Now, when the workflow runs again, any email with that Thread ID is correctly identified as already processed and filtered out.