Hello! We have a source of truth dataset in Airtable that gets written from HubSpot through a collection of Zaps. Essentially, this pipeline captures new Deals in HubSpot and writes them to AT with the intent of having a known-good copy in the case of errant (or intentional) data changes in HubSpot.

We’re investigating a way to have Zaps ‘listen’ for a change in HubSpot on a deal under a certain status (e.g. anything ‘Won’ with a previous date), then check that against our previously written Airtable data and rewrite HubSpot to match.

We’ve successfully written Zaps (which I would be happy to share) that perform this action. Our issue, however, is that HubSpot changes the “close date” to current day any time a property change is made. Some properties auto-save while others don’t commit until you click save. In either use case, this creates a cascading loop which triggers the same Zap several times before filtering itself out. At this point, the end result is still achieved, but at the expense of a huge taxing of Zaps running in sequence any time a change is made. As one could imagine, with several users in HubSpot touching deals, this stacks up very quickly.

My question: has anyone run into a similar experience, either with HubSpot/Airtable or other datasets that auto-write, or have best practices in preventing Zaps from looping?

Again, I’d be happy to go into detail or provide whatever info from our Zaps that may be helpful. Apologies if this is too high concept or vague, but we’re troubleshooting in real time. Thanks so much!