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 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.

How are new integrations added to Zapier?

  • 18 November 2019
  • 14 replies
  • 2469 views
Danvers
Userlevel 7
Badge +12

As a couple of folks were asking about this in another post, I thought it would be a good idea to start a new post to talk about how apps are added to Zapier's integrations.

@AndrewJDavison_Luhhu asked:

I've always been curious. What's the criteria where Zapier will step in a built an integration themselves? Is it where an app gets so successful, but efforts to encourage the app to build their own integration have just failed?

And @ChrisP followed this up with:

...it must be a nightmare for the Zapier dev team. They are in a tricky situation. Do they sunset problematic apps? Could cause chaos with existing automations. I've never heard of any app integrations being dropped but maybe @jesse or @Danvers could enlighten us on this.


The majority of new app integrations are added by the owners of the app. They are responsible for building the integration and once they have the integration ready for testing, we have a partnership team that works with them to prepare for a public launch.

We track requests for apps and if it looks like there's a real demand for something, our first step is to reach out to the app to see if they would be interested in developing an integration.

There's not a fixed criteria for deciding which apps Zapier builds an integration for, though when we do commit resources to building some, we will look at the whole list and take a few things into account, including the number of votes an app has.

When we build an integration, we will do what we can to encourage the owner of the app to take ownership of it as it does take a lot of work to maintain (and improve) integrations.

I hope that answers your questions @ChrisP and @AndrewJDavison_Luhhu!



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

14 replies

ChrisP
Userlevel 7
Badge

Thanks @Danvers What would be awesome is if each integration had a change-log history on its app page. Then, before committing a critical workflow to that integration, we could have a look at change-log history. It would also allow us to check in and see what new features have been added to existing. I know this is covered in the updates newsletter but only a tiny fraction of updates make the letter (more focused on new apps).

Some positive spin-offs of this would be that if I see a change that I know might make one of my apps unstable down the line, I could troubleshoot pre-emptively (and save customer support a whole bunch of stress 😉). Another benefit would be the transparency may actually motivate some apps to update more regularly. At the moment everyone is in the dark. Add RSS feeds to each changelog and it will be a real value-add!


AndrewJDavison_Luhhu
Userlevel 7
Badge +10

It's as I suspected @Danvers - and good to have this post to point people too in the future.

I guess as @alex mentioned, it's annoying when a very popular app like Asana just have no interest in taking over ownership of their integration, to the detriment of everyone involved. In these cases, though, I don't see why it's not possible to hand over maintenance of these integrations to a team of trusted 3rd party or community-lead developer groups. Maybe you can elaborate?

Also - you ought to give Notion a call (https://www.notion.so) not a day goes by without someone pestering them on Twitter for a Zapier integration... maybe they need a little encouragement 😅


We're Zapier Certified Experts - we help businesses do cool stuff with automation | www.luhhu.com
AndrewJDavison_Luhhu
Userlevel 7
Badge +10

Oh yes... I agree with @ChrisP here... and let me give a real world example.

Zoho Leads... you used to be able to assign a user as a lead owner, but with the integration's latest update, you can't (Zapier tells me it because of massive API changes that make this a lot harder).

I went ahead and updated my clients zaps swapping out to the new Zoho Leads version without noticing this... and by the time I did, the zaps were broken and there was no way back to the legacy version of the step 😁

A changelog would have saved us here!


We're Zapier Certified Experts - we help businesses do cool stuff with automation | www.luhhu.com
matthew

Developers are able to submit changelogs when they make updates to their integrations, but these are not currently exposed publicly. It's an interesting idea though — although I don't know how well it would play with integrations that automatically migrate folks to a new version, since you can't currently revert to an older version of an integration after being migrated unless you have an existing turned off Zap that is still on that older version.


AndrewJDavison_Luhhu
Userlevel 7
Badge +10

@matthew - that behaviour in itself is what caused problems in my case. I know it's risky to let people sit on older versions of apps, or allow people to roll back - but it would be good to have some options here, particularly when an updated zap comes with a breaking change.


We're Zapier Certified Experts - we help businesses do cool stuff with automation | www.luhhu.com
ChrisP
Userlevel 7
Badge

@matthew I had assumed that the majority of apps automatically migrate people over? My point isn't so much to object to the migration, but rather to get a headsup when it happens (which I could keep up-to-date with by subscribing to the change-log RSS). For example I often see new triggers and actions available in apps that I havent visited for a while. Presumably I was auto-migrated in these instances?

It would also be helpful if I get an error in a zap to go look at the change-log to see if any recent changes coincided with the error.


Danvers
Userlevel 7
Badge +12

@ChrisP Sometimes you might see new triggers or actions in an app because the team that owns the app has added one due to a popular feature request.

If we do need to migrate users from to an entirely new version of an integration (which can happen if the app involved has a new API for example), then sometimes users are automatically migrated to new versions, sometimes it's not possible as triggers or actions don't directly line up between the old and new versions.

From the sounds of it, it would be helpful for both you and @AndrewJDavison_Luhhu to have changelog so I've created a feature request for that and added both of your votes.


AndrewJDavison_Luhhu
Userlevel 7
Badge +10

Thanks @Danvers


We're Zapier Certified Experts - we help businesses do cool stuff with automation | www.luhhu.com
ChrisP
Userlevel 7
Badge

@Danvers 👍️


matthew

@ChrisP Most new integrations do automatically migrate folks, but it depends on the exact change being made. Migrations for non-Zapier-owned integrations are only recommended for non-breaking changes. Breaking changes (such as a new API endpoint, or a change to data structure or an incoming payload, etc.) are usually deprecated which allow you to continue to work with existing Zaps but not to set up new Zaps with them (you would have to copy an existing Zap in that case).

We also migrate folks over in certain other situations, e.g. moving folks from legacy web builder integrations to the new CLI/visual builder platform integrations.

I can see the utility in being able to switch between different versions of an app at will and compare their features to a known changelog — glad to see we've made an internal feature request for this changelog functionality.


ChrisP
Userlevel 7
Badge

Awesome! Thanks @matthew and @Danvers


PaulKortman
Userlevel 7
Badge +10

I'd love to be added to this feature request, and frankly why doesn't Zapier publish the feature requests... it would make it easier for me to cast my votes



Need Additional help? Feel free to reach out here: https://zapier.com/experts/connex-digital/
AndrewJDavison_Luhhu
Userlevel 7
Badge +10

@PaulKortman - very few established companies do - it's a trap.

The features users vote for the most don't always jive with the short/long-term goals or technical limitations of the company, so they sit at the top of the list getting more votes, but never getting built.

Roadmaps with general areas of improvement and ETAs work better - and @jesse mentioned in another post that Zapier is looking to more communicative with stuff like this - so fingers crossed 😅


We're Zapier Certified Experts - we help businesses do cool stuff with automation | www.luhhu.com
Danvers
Userlevel 7
Badge +12

Hi @PaulKortman I've added you to that feature request too.

As to making feature request public, @AndrewJDavison_Luhhu has covered most of the reasons why most companies (Zapier included) don't have public feature requests!

Jesse and I are working with the Product teams to bring more transparency to our roadmap. It's a work in progress so please bare with us, and know that we know how important this is to y'all!


Terms & Conditions