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!

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

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!

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.

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

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

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

Thanks @Danvers

@Danvers ️

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

Awesome! Thanks @matthew and @Danvers

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

@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

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!