About Zapier Community
New to our Community? Get to know more about our space and how to make the most of your time here.

Code of Conduct Community FAQ's Zapier Common Questions What to Expect

Get Started With Zapier
New to Zapier? We have got you covered with our Zapier 101 Resources.

Zapier Essentials

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

Zapier Products
Learn more about Zapier's new products.

Zapier Tables Zapier Interfaces

Zapier Reading
All of our best learning resources can be found here.

Featured Articles Show & Tell AI Hub Zapier Tools Hub

Learning Groups
Excited to meet other builders? Check out our interest areas full of doers, dreamers, and in-betweeners.

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.

Best answer

Trigger design best practices

  • 31 May 2023
  • 1 reply
  • 125 views
bc_andrew

We are writing our first Zapier integration and I have a question about how best to structure triggers that we expose.

Our system is similar to a CRM and looking at for example Hubspot triggers, they have a “New Contact” event _an_ a combined “Contact Create or Updated” event. Whereas we were planning on having separate “Created” and “Updated” events for our entities.

A common scenario for our customers would be syning contacts from our system to another.

Before we publish our V1, would there be any reason to favor one approach over the other? Any lessons learned from experience?

And is there a best practices guide for designing triggers that covers decisions like this?

Thanks!

icon

Best answer by MarinaH 14 June 2023, 22:20

View original
This post has been closed for comments. Please create a new post if you need help or have a question about this topic.

1 reply

M
Userlevel 4
Badge +9

Hi @bc_andrew  👋

Great questions and thanks for considering our mutual users’ experience as you build your first Zapier integration 🎉

There is some guidance on building triggers for a CRM app here: https://platform.zapier.com/partners/integration-examples#triggers-1 

Generally, it is good practice to have separate triggers for New and Updated items - as this allows your users to build Zaps for only new items (without adding a Filter step, which they would need to if there was a single trigger for a New or Updated Item) if they wish.

However, that also depends on the number of trigger items your app has - as too many triggers to choose from can be overwhelming for users as well - for example if you have multiple events that you’ll be offering a New or Updated trigger for. 

I can’t speak to the exact reason for HubSpot app choosing to have one New or Updated Item trigger, but that could be a factor (limiting total number of triggers to build/maintain/have users select from).

An opposing view would also be that a certain user may prefer a single trigger for a new or updated item, if they wish to perform the same action on those items - as they can then build just the one Zap for their workflow. But with easy functionality to duplicate Zaps, it is not overly burdensome for users to create another Zap with the same action and a different trigger.

It really depends on which event in your app you’re building the trigger for, and how you see our mutual users using it. Since you’re planning to have separate “Created” and “Updated” events for your app’s events, there is definitely no recommendation not to do it that way 👍

If you haven’t already, you’ll want to check out these integration review guidelines when you’re ready to submit your app for Publishing review. You can also choose to keep your app Private, with the differences described here. 

Terms & Conditions