Skip to main content

I love using Storage by Zapier as a simple place to build lists etc. 

 

However, I’ve recently run into a problem where a Zap will be triggered twice at the same time, and so the storage value will be unpredictably modified. Example below where One zap was triggered twice instance1 and instance2 at the same time (or nearly the same time).

 

at 10:00:03 instance1 stored “xyz” into the storage key of “my-key”

at 10:00:04 instance2 stored “abc” into the storage key of “my-key”

(some other Zap Steps occurred)

at 10:00:10 instance1 pulled “my-key” from storage and got the value of “abc”

at 10:00:11 instance2 pulled “my-key” from storage and got the value of “abc”

 

I could fix this if I could grab a zap instance or task ID, so I could store “xyz” into “my-key-instance1” and the next instance would store “abc” into “my-key-instance2” and then the instances would pull their respective instance named keys. 

 

I’ve tried things like grabbing a random value and storing that somewhere to use in the storage key name, but the moment I put it into a storage key the next instance will overwrite it (or might, depending on how fast the tasks are etc) 

 

Essentially I want a way to have storage values be shared across all zaps/zap instances (this is the way it works now) But I also want a way to have this storage key/value be only available to this instance of this zap. 

 

I’ve had to resort to adding a delay by queue which also adds an unnecessary 60 second delay/penalty on each instance of this zap. 

 

Do you have any bright ideas on how to fix/overcome/solve this dilemma? From what I recall Zap Manager does not have a way to provide us with the current Zap instance/Task ID. 

 

Thanks.  

Hi @PaulKortman,

I think I know what you mean, but just to make sure would you be able to give me a more specific example of which triggers/actions a Zap could be using, where you’d like to use Storage in the way you described? I think that will help me wrap my head around what you’re trying to accomplish. Thanks!


In this specific example we’re triggering off of a ticket being updated in a helpdesk platform. Multiple tickets can be updated at the same time or within seconds of each other. 

 

I’ve taken a workaround method of adding the ticketID and the timestamp of the update to the ticket to the Key, so now my storage key looks like: “all-notes-4567-04/28/202005:45:34 (and I have an extra formatter step to trim it to 32 characters) This is as close as I could get to a unique Key for this zap instance. If I were to use the timestamp of the ticket update alone it could overwrite another instance running on another ticket that was updated at the same second, and if I used ticket numbers alone it could conflict if the zap instance takes longer than a few seconds (which it does because there’s a 1 minute delay in it) and if the same ticket had two updates to it within a minute to it. 

 

I’m using storage because we have to make a webhook call in the zap back to the ticketing system to get all the attached notes. However the notes come back as an array (I cannot change that) and it causes the rest of the zap to “fork”  Here’s my illustration of forking, it’s not like paths where it is set up within the zap to choose which path to take, “forking” as I’m using it is running the rest of the zap multiple times (once for each item in the array that is returned)

 

The two steps after the webhook are repeated for each note in the webhook results

 

So I use a storage list where we add each “note” into the storage list and then retrieve all values from the storage list to finish the rest of the zap with. 

 

(On a side note, I also use a storage key to increment how many times the forking happens and a filter after that to exclude anything after the first run, but I use a delay to allow the other forks to write their information into the list.)

 

Thanks to the incremented storage and the red filter now only one fork finishes

 

I know this isn’t a typical setup, and this really is a bandaid for a poorly formatted result of a webhook… but it has worked before and the only issue is trying to setup a storage key that is unique to this zap instance.