Skip to main content

Get Support
Have a question? Let's get you an answer!

How Do I...? Troubleshooting Code & Webhooks Developer Zone

Other Help Resources
Wait, there's more! Check out these Community sourced spaces for additional resources.

Zapier Help Center Hire an Expert

Learning Resources
All of our best learning resources can be found here.

Featured Articles Show & Tell Zapier's products AI Hub Zapier Tools Hub

Share your knowledge
Give back to the Community by sharing your automation wins and helping to answer questions.

Share your success See unanswered questions User Groups

Other Learning Resources
Some of our favorite additional ways to upskill your Zapier knowledge.

Zapier Learn Zapier Blog Zapier Webinars

Product Updates
Check out what is new and upcoming with Zapier with our regular product updates.

Product Updates

Early Access Program
Want to join Early Access? Learn more here.

How to avoid a Zap loop works well with creations but not with updates. In my case, if I create a Jira ticket which gets propagated to Google Calendar as an event, I'd like to know I can ignore a trigger from Google Calendar since that update was issued by Zapier.

This means that the question we're trying to answer is “Was this zap triggered by a user or by Zapier?”

The easiest way to do this is by attaching a checksum to the update. Just like cryptographic signatures. Say we are propagating from Jira to Calendar:

Date: 2025-01-02
Description:
Hello World!

Concatenating those values and then attaching a checksum (e.g. crc32) you could propagate the Calendar event like this:

Date: 2025-01-02
Description:
Hello World!
CRC32=9C 12 95 FA

If Calendar sent back an update to Zapier, Zapier would parse the description field, extract the checksum and concatenate the date and the actual description. This way it would be able to see that the checksum hasn't changed, thus, this was a Zapier triggered update and not user triggered.

This solution has however two drawbacks:

  1. Description field looks ugly
  2. Calculating the crc32 is an extra task

#1 is hard to circumvent and I'm willing to deal with it. In fact I'm attaching a key as well at the bottom of the description to be able to find the calendar event back in Jira as a ticket. This limitation is unrelated to Zapier

#2 however could be solved. We just need a crc32 spreadsheet function and no additional task would be needed. Right now I need three tasks:

  1. Calculate CRC32 checksum
  2. Find Event (or Create)
  3. Update Event

The rest of the text transformations are not tasks which is great. This solution could be using 33% less tasks if such a (simple) checksum function existed.

Hi ​@andras 

Perhaps you can use Zapier Tables as your lookup table.

Available Zapier Tables triggers/actions: https://zapier.com/apps/zapier-tables/integrations#triggers-and-actions

Zapier Tables used in Zap steps count as 0 Tasks.

Hi Troy,

 

Thanks for taking the time to read through it. How would you use look up tables to calculate a checksum? Or you mean something else?

 

cheers,

Andras

​@andras 

The Zapier Table would be used to log the checksum to check for.

You would define the logic for the checksum in the Zap steps.

​@andras 

Perhaps consider using this Zap action: Formatter > Date & Time > Compare Dates

You can use this followed by a Filter step to check the GCal Event updated timestamp vs the time when the Zap is triggered to run and set your desired time threshold as to whether to continue or not.

 

​@andras 

The Zapier Table would be used to log the checksum to check for.

You would define the logic for the checksum in the Zap steps.

Hi Troy!

If I understand correctly, you're proposing to store the checksum in a look up table rather than attaching it to the content. This would mean calculating the checksum on update and looking it up in the table to see if it equals the last known value. If not, replace the checksum in the look up table and push the update through.

I like the idea which would solve the first problem which is attaching the checksum. If I understand correctly, the same idea could be used to store the calendar ID in a look up table thus avoiding to have the KEY attached to description/summary as well. I'll play with this to see what I can find.

​@andras 

Perhaps consider using this Zap action: Formatter > Date & Time > Compare Dates

You can use this followed by a Filter step to check the GCal Event updated timestamp vs the time when the Zap is triggered to run and set your desired time threshold as to whether to continue or not.

 

I like the pragmatic idea, but this is prone to missing updates and racing conditions (older update over newer update) under some circumstances.

Thanks for the advice though. Highly appreciated.

cheers,
Andras

Ok, just reviewed the solution. It would be indeed possible to store the checksum and the Jira key id + Calendar ID for identification. This would solve issue #1 completely which is how to keep the contents tidy.

I appreciate the effort on #2 with the dates, but that just won't cut it. Especially since I have double updates coming from Jira because of automations. In that case I'm interested in the second update (and not the first one), but it would be impossible at any point in time just using keys/ids/checksums and update dates to know if the update is user triggered, Jira triggered (automation) or Zapier triggered.

The feature request for:

  1. Built-in checksum function
  2. Ability to obtain the Jira description field without needing additional tasks

Are still needed. #2 has a dedicated topic:

 

​@andras 

Advanced approaches can use app APIs/webhooks:

 

Best to submit feedback and feature requests via a ticket to Zapier Support for those to be properly logged: https://zapier.com/app/get-help

 

Hi ​@andras 

Maybe you are still searching for a satisfactory solution for this.

Are you aware of the etag property on the Google Calendar accessible by Zapier?

The Etag on the event changes everytime the event is updated, by Zapier or by a user, or another app.

This builds on the table solution above, but you avoid all the timestamp, date calculation mess. And the time it takes etc. Especially with simultaneous updates of the event.

  1. Create/update Google Calendar event in Zapier and store the Etag in the Zapier table next to the Event ID
  2. When your New/updated Google Calendar even triggers retreive the record matching the Event ID
  3. Use a filter to compare the Table Etag vale with the event trigger Etag value, the EXIT if they match i.e its just Zapier, Or continue if they don’t match because it is user generated

I think the Etag value is what you were looking, Happy to look further if I have misunderstood though.

 

I Hope this helps :)

Tell us how it goes

Hi Shane,

 

Thanks for the addition! This would solve the requirement of a checksum from the Calendar side. And following up on this approach, I could just keep the Jira checksum *input* in the lookup table. This would store a "large" string, but provided string limits allow it, this approach would completely remove the need of a checksum function. Not pretty but could work. I'll let you know what I can find. Thanks!

 

cheers,

Andras

​@andras 

 

I’m glad that was helpful.

I don’t know anything about Jira unfortunately. 

The only thing I can think of, in a general sense, is could you have Jira tell Zapier to update events on the Calendar instead of updating them directly from Jira? (if that is even what is happening).

This would mean Zapier makes Calendar updates for all automation/app updates = one check of the Etag, avoids any Jira loops on the Calendar (if this was an issue) and means not passing Jira strings for checking etc and having to deal with any sync issues.

Reply


Terms & Conditions