Hi @Andrew Recruit10!

We don’t have that sort of functionality available at present but it’s a really great idea! I’ve gone ahead and passed your suggestion over to the Product Team for consideration. I can’t make any promises around when/if it’ll definitely get implemented but we’ll be sure to let you know if it is. 

If you have any further questions or if there's anything else we can help with in the meantime do let us know! 

Hey, @Andrew Recruit10 - I would love to get a few folks engaged in this conversation and get some better ideas.  I’ll explain what I’m doing today - it is - at best - clunky.  That said, I have made some improvements based on some learnings.  

So, here goes:

1.  I have folders named Dev / Test / Prod as well as archive folders for each.  When I’m going to do a new release, I rename the (for example) Prod folder “Prod Archive 1”.  Then I create copies of the latest version and move them to a new Prod folder. 
    
2. Once the Zaps are in the new prod folder, I have to point them at the right environments / accounts (e.g., switch from a Sandbox account to a live account).  <SoapBox>It would be a HUGE enhancement if Zapier enabled me to link accounts at the folder level instead of the step level.  I have one system that’s probably used in a dozen steps across 5 zaps.  Manual changes are error prone and high risk - not what you want when going to production.  My preference would be that all I had to do was copy the Zap into the Prod folder and it would inherit the “accounts” of the folder.  They’re also very repetitive if the same system is used in multiple steps and Zaps. </SoapBox>
    
3. I am working with a primary system that drives many of my Zaps.  For that system I have Dev/Test/Prod, but for other 3rd party systems I only have Dev/Prod.  One thing that I’ve done is started passing an environment parameter from the “driver” system that specifies what environment is being used.  That is helpful, because instead of having to change code “in production” I just handle the various environments in code/conditions.  E.g., Some downstream systems need to know a URL and the URLs are prefixed by the envt code.

Like I said - clunky.  Also - oops - soapbox again - the newish Zapier UI isn’t great because I see the names of Zaps but can’t tell whether it’s the dev / test / prod version.  So I waste a lot of time navigating around… I’d ideally want the Zap to have the same name across environments and some notation of what folder it’s in on the “home screen”.

I’m also trying to figure out how to engage a team to work on Zapier and feeling a healthy anxiety on managing roles and access.  It’s a big jump from Pro to Team.  We’ll see.

Hi @soz 

What you’ve described is exactly what I was thinking about implementing. However I’ve realised that it’s too clunky and too error prone, exactly as you’ve pointed out, so I’ve put it on the backburner but I’m going to have to do something soon.

Your comment about working a team into this is another related issue too.

This really is a Zapier product development issue. @SamB I’d love to know if there was appetite in the product development team for this?

This is really a bigger CI/CD/DevOps thing, but I suspect that Zapier is less often used by large teams with lots of resources to manage that kind of thing, however something is definitely needed to address this.

I like the simple way that Microsoft does this with what they call “Environments” and “Solutions” for Power Platform Apps and Dataverse Databases, but Zaps with multiple systems and their authentication is a little more complex.

Surely this must have been raised a thousand times. Surely someone out there has a solution.

Andrew

Right @Andrew Recruit10 .  I’m a solopreneur right now and this barely works at my scale - about 6-8 active Zaps and a handful more in development.  I don’t understand how any serious company with more than a couple of Zaps can live with this. I’m all about automation and love the ease and simplicity of setting up Zaps. This is a real obstacle. I haven’t (yet) looked at competitors to see if they do it better, but this approach is unlikely to work for me beyond the next 6 months. 

Apologies for missing your replies here previously, @Andrew Recruit10 and @soz.

@SamB I’d love to know if there was appetite in the product development team for this?

I can’t confirm whether it’s something that’s definitely going to be built in the near future but we’ll definitely let you both know if it is! 
 

I’m also trying to figure out how to engage a team to work on Zapier and feeling a healthy anxiety on managing roles and access.  It’s a big jump from Pro to Team.  We’ll see.

Not sure if you’ve already taken a look at this but I wanted to share our Manage team roles and permissions guide here in case it’s helpful to see what different levels of access/permissions can be applied to team members. 

I agree, you’re likely not the only ones interested in these types of functionality, I expect there’s a lot of folks that would also be interested. Please know that I’ve sent all the comments and ideas you’ve both shared over to the Product Team so that they’ve definitely been put on their radar! 

Thanks, @SamB - I’m impressed with Zapier and intrigued by all the new functionality (tables, ai, etc) but can’t imagine using it all if there’s not a better way to manage/deploy it.  

Really pleased you’re liking the new functionality, @soz.  

We totally hear you on the need for better management and deployment of Zaps. And I do hope that we’ll be able to deliver on that side things in the near future! 

+1 for tools/options around managing environments.

I’m here too building an integration for my product and a bit surprised by the fact that developer experience is lacking behind considering Zapier has been around for 13 years :/

Hi @Andrew Recruit10, @soz and @liger!

I did some further checking and spotted that Functions, our new code-first automation tool (currently in Alpha) has deployment functionality that you might be interested in exploring. You can learn more about Functions here: https://zapier.com/functions. 
 
If you’d like to give Functions a try, you’ll need to first join our early access program. Once you’ve done that a member of our Product team will get in touch via email with next steps.

@liger - it sounds more like you may be building an integration for your product on our Developer Platform rather than wanting that sort of functionality for building/managing Zaps. If that’s correct and it’s a CLI built app integration you can learn more about how to manage/deploy different app versions in our Deploying an App Version guide.

Hope that helps!

Hi @SamB & @soz By chance I looked at that page about Zapier Functions and watched the video yesterday, though I couldn’t find much more on it. It looks fantastic. If that kind of functionality was in Code by Zapier I’d be very, very, very, happy.

Your suggestion sounds like it could be a good idea and with other CI/CD/DevOps tools maybe it could work, and I plan on testing it. However it’s an Alpha so it can’t be relied on for production.
 

Functions still doesn’t solve the bigger issue of managing Zaps and the point of Zapier is keeping it simple and low cost. Again (for your features people) I really like the way that MS Power Platform handles this with Environments and Solutions, it’s just simple.

I’m so pleased to hear that you like the look of Functions, @Andrew Recruit10!

Totally understand that it’s not production ready at present but I do hope it may be helpful to you all in the near future once it’s out of Alpha. 

Functions still doesn’t solve the bigger issue of managing Zaps and the point of Zapier is keeping it simple and low cost. Again (for your features people) I really like the way that MS Power Platform handles this with Environments and Solutions, it’s just simple.

I’ve logged this with the Product Team but I’d also recommend submitting your idea to have similar functionality, to what Microsoft’s Power Platform has, added to Functions. You can submit a feature request for that via the form here: https://functions.zapier.app/contact. 

This will help to get the need for that type of functionality on the Functions team’s radar and allow us to keep track of overall customer interest in this. And allow us to send you an email notification when/if it’s added. 

Hi @Andrew Recruit10 
We have been managing our Test / Production environments by registering the app multiple times.
You can then create a copy of the .zapierapprc file multiple times within a project & append the name of the environment to the front e.g. TEST.zapierapprc, PROD.zapierapprc

This allows you to only require a single project that supports multiple environments. 
You can then configure your CD Pipeline to replace the environment .zapierapprc file with the main one and boom you now have a single zapier project that supports multiple environments :)
e.g. 

TEST.zapierapprc -> .zapierapprc

Hi @nick.m,

Thank you sharing your resolution with this concern. @Andrew Recruit10 you can try his recommendation with this one. Let us know if this helps you with your issue.