A sweep that adds each missing registrant once
A fifteen-minute Make scenario reads the registrants and the event tracker in one request, works out who is missing by set difference, and adds only them (two operations when there is nothing to do).
Where this applies
Event organisers, programme teams and anyone who reconciles registrations against a tracker.
- rows backfilled in the first run
- ~57
- per run when nothing is missing
- 2 ops
- sweep interval
- 15 min
The problem
Event and programme staff work from a tracker, and everyone who registers has to be on it. Registrations arrive by more than one path, and instant automations only cover some of them. A person missing from the tracker is a person nobody follows up.
A person on it twice is a different problem: two rows, two sets of notes, and staff unsure which is current. Any fix has to add what is missing without ever adding anyone twice.
What we built
One read, two answers
A single GraphQL request carries two aliased queries: up to three hundred registrants in the right group with the right event selected, and up to five hundred existing tracker rows with the ids of the candidates they link to. That is the whole read cost of the run, regardless of how many people are registered.
Idempotency by set difference
The scenario builds one comma-delimited string of every candidate id already on the tracker and creates a row only when the registrant's id, wrapped in commas, is not in it. The commas matter: without them id 12 would match inside id 112. A run immediately after another creates nothing.
Rows born linked
Each new row is created with its candidate relation already set. An earlier version tried to create the row and then write the relation from the candidate's side, and Make's first run failed on the shape of that value; the rewrite creates the row with the link already set in a single mutation.
Why polling is the right tool here
Registrations can be edited after the fact, and a webhook only tells you about the edit it saw. A sweep every fifteen minutes needs no memory of what happened; it compares the world as it is to the world as it should be, so a late or edited registration is picked up on the next pass.
The outcome
The first run backfilled about fifty-seven registrants who had no tracker row, in fifty-nine operations.
Every run after it has cost two operations and about three seconds: nothing to do, and nothing done.
The tracker and the registrations are compared on every pass rather than by someone checking.
Where it stops
The read is paged at three hundred registrants and five hundred tracker rows. Past those volumes a registrant could be missed and a row duplicated, so the limits should grow with the event. A candidate added to the tracker by hand without the relation set will be added a second time.
Built with
- Make.com
- monday.com
- GraphQL API
Patterns used
- Set-difference idempotency
- Aliased GraphQL read
- Scheduled sweep
Page copy drafted with AI assistance. Skofi is accountable for it. Editorial policy
Have something shaped like this?
If any part of the above resembles a problem you are living with, a short call is the fastest way to find out whether it is the same problem underneath.
What happens on the call
- 15 minutes, no deck
- We map the process on the call
- A written scope, or an honest no