Skip to main content

Hi everyone,

I have a very interesting use case that some others might have run into as well. The use case is for Hubspot contacts and deals and updating these in a third party app or other database.

 

Here is the issue: There is no way to have a trigger that notices a change to hubspot associations. That is, if you change a contact associated with a deal - there is no trigger for that.

A workaround I have created is to use the trigger ‘update on property change’ and use the property change ‘last modified time’.

 

But now there are a LOT of triggers that are created. Every chat, conversation, email, phone call, everything is a trigger.

So then I dealt with it in three parts:

  1. A trigger system that sends a webhook
  2. A catcher system that sorts and filters these triggers and passes on to the actual updater
  3. The updater that updates the database with all sorts of interesting things (looping through associated contacts to get their details and update them for example) but this is not a concern for the time being.

The Trigger goes like this:

  1. Receive trigger
  2. create a key in storage by zapier with Key: CID_{Deal_ID}
  3. send webhook

The Catcher goes like this:

  1. Receive webhook with Deal_ID
  2. Go into delay by zapier queue with queue name Q_{Deal_ID}
  3. once out of delay use storage by zapier to find key CID_{deal_ID}
  4. Filter by zapier to continue only if a value is found at CID_{deal_ID}
  5. It runs some other checks (not important) before sending a webhook to the actual updater and then:
  6. Uses storage by zapier to erase the key and value at CID_{Deal_ID}

In theory what this should do is:

  1. Allow many triggers to be triggered
  2. Queue up those triggers
  3. Only allow the first trigger to actually move past the 4th step in the Catcher workflow

The issue I am having is this:

  1. The trigger system receives a trigger and stores a key and value. This key is CID_{deal_ID}
  2. A heap of these triggers run at say 04:15:00 - the last one finishes at 04:15:10
  3. A bunch of Catcher zaps begin running
  4. They all queue correctly, releasing every minute one by one from 4:16:00 onwards
  5. The first one is the only one meant to pass.
  6. It then sends a webhook to the actual updater, then clear the key and value at CID_{Deal_ID}

Unfortunately what is happening is for every single Catcher workflow is running and is finding a key and value at CID_{Deal_ID} when none should exist.

Is this a zapier caching issue? Is there another inbuilt delay? Are zaps that use a find storage step finding that storage value on zap initialisation instead of when the step actually runs (say, after a delay step)?

These are the only answers I have.

 

If anyone has any suggestions please hit me up.

If you have any suggestions about how to deal with a better trigger for updated associations for hubspot deals also please let know.

Hi @SeanWilson 

Yes, there is some caching that occurs in Zaps.

See below for a response about caching in Zaps from Zapier Support:

 

You can try adding a cache buster such as a Timestamp to those requests: https://zapier.com/help/create/customize/insert-the-time-your-zap-runs-into-a-field

NOTE: When you manually test a Zap step, you will not experience caching.

 

Check the available help articles for Storage:

https://zapier.com/apps/storage/help

 

You can try opening a ticket with Zapier Support for further assistance: https://zapier.com/app/get-help

 

###

 

RESPONSE

The quick answer here is that Search steps in Zapier are cached.

So if you search the exact same thing you'll get a cached result and not the current values from the Sheet.

There isn't an exact time for how long it will take for the cache to clear.

Generally - I'd set a delay of 4 minutes in a Zap to work past this issue (if it is an issue in a live Zap).

But for testing like you are - the only real solution is to wait 4 minutes and run the Search again.

Again - that 4 minutes is a good number with a bit of a buffer.

It likely takes slightly under 3 minutes for the cached to actually be cleared.So again to summarize.Searches are cached for 3-4 minutes.

If the issue is just with testing Zaps - the solution is to wait 4 minutes and search again.

If the issue is in live runs of the Zap - the solution is to add a delay step (most likely a Delay After Queue step) for 4 minutes.


OK so it seems what you are saying is that I should be writing the key and checking the value of that key (which I do already) but making sure the value for that key is unique for every trigger?

 

In this sense it would overwrite the cache, and the best and easiest way to do that is to make they value zap_meta_human for example?


@SeanWilson 

Is the goal to have Zapier trigger only when a deal’s associated contact’s change? So for example Deal A is associated to Contact B & Contact C. Trigger Zapier if Deal A becomes associated to just Contact C? 

Am i understanding it correctly? 


@GetUWired thats exactly right. A contact is associated with a deal so you have to have a trigger that runs on an association change.

 

but there’s no trigger.

so you have to use on property change and use last modified time.

 Now you have a trigger on everything haha. 
 

but yes I needed something set up so we could run it when a contact changed on a deal or a second contact was added or the third contact was dropped etc


@SeanWilson 

Have you tried running it on changes to the field number of associated contacts? 

Alternatively, you could try and use Google Sheets with a flow like the below. 
Zap 1: 
Trigger: Deal Last Modified Time Changed
Action: Hubspot - Find Associations
Action: Sheets - Find/Create Row on Sheet. Basically using a column on the sheet that has the combination of deal id and associated contact ids as your search column. The logic being that if the associated contacts change then a corresponding row won’t exist. 

Zap 2:
Trigger: New Row added in Google Sheets
Action: Continue with the flow that you need. 

I believe the above would work pretty well. The only exception being if a deal is associated to Contact A & B then just A, then back to A & B in which case your sheets database would’ve have already registered that combination and zapier wouldn’t fire.