Bigquery scenario uses too many credits daily and needs to be improved

[Prospex]

What is your goal?

I want to redesign a Make scenario that syncs Notion meeting feedback status to a BigQuery dashboard, while using far fewer operations/credits and avoiding repeated BigQuery DML updates.

The goal of the scenario is:

• Find meetings in Notion where Status = “Afwachting beoordeling”
• Only include meetings where the meeting date/time is in the past
• Only include meetings linked to an active profile
• Show those meetings in our BigQuery dashboard as “to_be_rated”

The client rates the meeting through a feedback form. Another Make scenario processes that feedback and updates the Notion status to statuses such as “Done”, “Afspraak verplaatsen”, “Verplaatst naar andere datum”, or “Canceled”. So Notion is the source of truth for whether a meeting is still waiting for feedback.

I am looking for a safer and more scalable scenario design. Ideally, I want to avoid updating the large BigQuery event table directly for every Notion item.

What is the problem & what have you tried?

The current scenario uses too many credits and regularly ends with warnings.

Current scenario structure:

1. BigQuery module:
   Reset to_be_rated to null in the large event table.

2. Notion Search Objects:
   Search for database items where:

   • Status = “Afwachting beoordeling”
   • Meeting date/time is before now

3. Sleep module:
   4 seconds

4. BigQuery module:
   For each Notion item found, set to_be_rated = true where taak_ID = Notion Page ID and hook_event = “meeting.scheduled”.

The issue is that the Notion search can return hundreds of items. The last BigQuery module then runs once per Notion item. In the scenario history, a single run takes around 45 minutes, uses around 690–740 credits, and often ends with a warning.

I tested the first BigQuery step safely with a SELECT query instead of UPDATE. It showed that 329 records would be reset to null.

I also tested one specific Notion appointment and confirmed that the BigQuery relation works:

• request_connection_and_chat.hook_name = profile_info.Email
• profile_info.Status = “Actief”

The appointment was found in BigQuery with:

• hook_event = meeting.scheduled
• hook_name = maxim@marcus.agency
• profile_status = Actief
• date_time_meeting populated correctly

So the data mapping seems to work, but the scenario design is inefficient because it does one BigQuery update per Notion item.

I am not very comfortable making changes directly to the large BigQuery table, so I want to know the safest architecture.

Error messages or input/output bundles

The recurring warning/error is:

Execution was FORCED to stop because MAXIMUM EXECUTION and OVERLAY TIMEOUT [45 minutes] had elapsed.
Execution was requested to stop.

This happens repeatedly in the scenario history.

Typical run details:

Status: Warning
Duration: around 45 minutes
Credits used: around 690–740 per run
Interrupted module: the last BigQuery module after Notion Search Objects and Sleep

The scenario structure is currently:

1. BigQuery - Run a Query
   Resets to_be_rated to null in the large BigQuery event table.

2. Notion - Search Objects
   Searches for database items where:
   - Status = "Afwachting beoordeling"
   - Meeting date/time is before now

3. Sleep
   Waits 4 seconds.

4. BigQuery - Run a Query
   Sets to_be_rated = true for each Notion item found.

The issue seems to be that the Notion Search Objects module can return hundreds of items. Because Make processes each returned Notion item as a separate bundle, the Sleep module and the final BigQuery module also run hundreds of times.

So one execution can effectively become something like:

1x BigQuery reset
1x Notion search
hundreds of Sleep operations
hundreds of BigQuery update operations

This appears to be why the scenario reaches the 45-minute execution timeout and uses so many credits.

Current relevant BigQuery table:

prospex-social-assistant.social_assistant_events.social_assistant_reporting_request_connection_and_chat

Relevant fields:

taak_ID
hook_name
hook_event
date_time_meeting
to_be_rated

Profile table:

prospex-social-assistant.social_assistant_events.social_assistant_reporting_profile_info

Relevant fields:

Email
Status

Relation between the tables:

profile_info.Email = request_connection_and_chat.hook_name

Only active profiles should be included:

profile_info.Status = "Actief"

Current BigQuery update pattern in the last module:

UPDATE `prospex-social-assistant.social_assistant_events.social_assistant_reporting_request_connection_and_chat`
SET to_be_rated = true
WHERE taak_ID = '{{4.id}}'
AND hook_event = 'meeting.scheduled'

This update currently runs once for every Notion item returned by the Notion Search Objects module.

I also tested with SELECT queries instead of UPDATE queries to avoid changing data directly.

One test showed that the first reset step would affect 329 records.

Another test with one specific Notion appointment confirmed that the mapping works:

taak_ID: matched the Notion Page ID
hook_name: maxim@marcus.agency
hook_event: meeting.scheduled
profile_email: maxim@marcus.agency
profile_status: Actief
date_time_meeting: populated correctly

So the data mapping seems to work, but the scenario design is inefficient because it performs repeated BigQuery actions per Notion item.

I am looking for advice on how to redesign this safely. I am especially wondering whether it would be better to:

1. Use an Array/Text Aggregator after the Notion search and run one BigQuery query with all Notion Page IDs.
2. Create a small separate queue/staging table in BigQuery containing only the current taak_IDs that need to be rated, then have the dashboard join against that.
3. Avoid updating the large event table entirely and solve this through a BigQuery view/query.
4. Use another Make/BigQuery pattern that avoids hundreds of DML statements.

My main concerns are:

- Reduce Make credits/operations
- Avoid the 45-minute timeout
- Avoid hundreds of BigQuery DML statements
- Avoid directly updating the large BigQuery event table if possible
- Keep Notion as the source of truth for meeting feedback status
- Filter out inactive profiles using profile_info.Status = "Actief"

Create public scenario page

I cannot share a public scenario page because it contains internal client data and BigQuery table names.

Screenshots (scenario flow, module settings, errors)