I’m working on a dashboard that tracks daily booking approvals through an automated pipeline. My PostgreSQL query counts distinct bookings for the current day:
SELECT COUNT(distinct res.reservation_id) AS "metric_id"
FROM reservation_logs res
WHERE res.status IN ('confirmed', 'auto_confirmed') AND
res.timestamp >= CURRENT_DATE AND
res.timestamp < CURRENT_DATE + INTERVAL '1 day';
The issue I’m facing is weird. For the first day, my dashboard updates correctly when new reservations come in. But after 24 hours pass, the metric completely stops refreshing even though running the same query manually shows the numbers are definitely changing.
I read through the automation platform documentation and found this note: “Once the system has processed an item for a workflow, it will never trigger again even if the item is updated later.” This explains why my daily metrics only work for the first 24 hours. Since the same outcomes have been seen before, they won’t trigger updates anymore.
Has anyone dealt with this deduplication behavior for daily metrics? What’s the best way to handle this scenario?
Been there with metrics pipelines. The real problem isn’t deduplication - you’re stuck reacting to issues instead of controlling them.
I had the same headache with our booking analytics. Ditched Zapier’s weirdness and switched to Latenode. Set up an hourly workflow that pushes current counts to Geckoboard whether they changed or not.
Latenode connects to PostgreSQL directly, so your query stays the same. No hacky workarounds or extra timestamp columns. Just automation that works beyond day one.
Your dashboard gets hourly updates, and you’ll never deal with broken deduplication logic messing up your metrics. Easy to add complex logic later too.
This is a classic automation platform gotcha. Don’t mess with your existing query - build a separate tracking table for daily snapshots instead. Just insert a new row each day: INSERT INTO daily_metrics (date, booking_count) VALUES (CURRENT_DATE, your_count_here). Then trigger off these inserts, not the reservation data. Each snapshot is a genuinely new record, so deduplication can’t touch it. I’ve been running this setup for months with zero issues, plus you get historical trend data as a bonus. The trick is monitoring your metric snapshots rather than the raw source data.
Had the exact same headache 6 months ago with a similar setup. The deduplication is killing your updates after day one. I fixed it by adding a timestamp to make each record unique in Zapier’s eyes. Modified my query to include NOW() as update_timestamp - now the automation sees each run as a completely new record instead of the same data getting updated. Also tried switching from using the raw query as a trigger to a scheduled zap that runs every few hours and pushes the current count whether it changed or not. You’ve got to work around the platform’s deduplication logic, not fight it. Make each metric update look like a distinct event with its own unique fingerprint.
yeah, super annoying but there’s a solid workaround. skip the data change triggers entirely and set up a time-based one in zapier that runs hourly. have it pull the current metric value every time, regardless of changes. this completely bypasses the deduplication mess since you’re pushing data on a schedule instead of waiting for changes.