That's a great question! In terms of names, I usually go for something descriptive like 'Slack question to Airtable' and I use folders to keep things tidier.

One thing that I do is always fill in the notes section of the Zap, so that if someone wants to edit it, they know what the Zap does and why the different steps are there.

And don't forget that you can search for a Zap using the name of an app that's in it! That can save time when looking for a specific Zap :)

How does everyone else manage their Zaps? Have you found a system that works well for you?

Trying to repurpose a comment that I posted on the prior community forum that involves this same question:

Dashboard Zap List View

There's currently no easy or standardized way to document the more complex Zaps. I have been using this type of structure for a while for the naming scheme of a zap:

CLIENT - (2|5) [v4] [copper] (Opportunity - Project) Active Job Stage > [qbo] Find/Create Customer > [qbo] Create Invoice > [airtable] Lookup Project Lead Name For Email Address > [copper] Create Activity > [copper] Da (TRUNCATED - TOO LONG OF TITLE)

So a few things. There is a lot going on above, but I can skim a zap and have a pretty good idea of what is going on. Zapier only shows the Trigger + # + Final Action which isn't very helpful for a 4+ step zap. Naming it like I have above is not very easy on the eyes and it is starting to get a bit overwhelming.

Documentation Inside of Zap

Then there is actually jumping into the zap. I try to label each trigger/action title with what it is doing. Something like this:

Lookup Project Lead Name For Email Address

But it gets truncated after the first 3-4 words so it's impossible to easily skim.

Then there is the native "Add a note" option within the zap, but it is so hidden and out of the way, and I have typed up essays in there before and forgotten to "save" enough times to get frustrated to not use it much anymore.

At the end of the day, it is out of sight, out of mind. It is not easily skimmable/referenceable.

So then we start storing this information in external tools like Airtable and Coda, building out things like this (will upload pic later):

AND / OR THIS

To share with clients or just for internal documentation. But then you update Zapier and boom, this is out-of-sync and then your job turns into documenting and updating that information versus just building solid zaps.

I don't know about you but this takes up a TON of my time. I think you should be documenting for your clients if you are going to be doing business process consulting and automation. It's part of your service offering.

You can also use something like Business Process Flow-Charts/Mapping but that often doesn't include a ton of information.

At the end of the day, I wish that Zapier allowed for an option to document along the way better (for each trigger/action/filter) and better yet, I wish there was a way to export/sync zap information to be in a more standardized process map type of way (a living accessible URL documentation view of it). This shouldn't be stuff that you have to be manually building out. I think there is a huge value prop here with Zapier helping with documentation or at the very least allowing for easier documentation/best practices.

Does anyone else document outside of Zapier due to the above frustrations?

Further Breakdown of Zap Naming Scheme

I essentially have the client’s short-code first so I know when a zap runs what client it is for (team accounts = task history with everything in it (which I love) but I need to be able to easily/quickly know what client it is for when skimming through).

I then list each action/app that is involved with the zap. .copper] What Is Being Done > ;qbo] What Is Being Done > etc.

That was I can easily search/filter zaps down by the software (essentially creating metadata to reference) and it allows us to easily skim automations to know what is going on without jumping in/out because that is super super super slow.

If the Zap is related to the CRM (many are), I will have (x | x) for me to quickly know (1 | 2) - means pipeline 1, stage 2. Or for status of an opp, I have (x | W/L/A) for pipeline & won/lost/abandoned.

Finally, if I massively change a zap, I will have made a copy of it prior, and then I will add versioning to it tv1]

pv2] ]v3], etc. - I will then take the old zap, add an xOLD before the name, and file it away into an CLIENT - xOLD Versions folder.

Here’s a quick look at a few of our zap names:

AKA I wish more meta data was pulled from inside of the zap (action software/type & action title) to easily skim in the zaps view because I’m currently doing that manually and it is painful to keep updated.

Hey @alex thanks for posting this here! Looking at your naming convention, it seems like these are the most important things for you to sort on:

• Client
• App (and potentially the version of the app or Zap?)
• Trigger/Action name
• Custom notes/keys

Does that sound correct to you? I definitely understand that currently, there is no way to visualize this all at once to find the correct Zaps and that you're having to document this internally. It also sounds like some find of internal trigger for updates to Zaps (adding steps, renaming, etc.) might be good to have so you can keep an external database of information in sync and up to date for your clients.

Your idea for a living accessible URL documentation view of it sounds super interesting and definitely something that I would love to share with my team. When you have a sec, are you able to mock up how you'd like this "documentation view" to appear? If you could design this, how would one access it and how do you see yourself using it?

Let me know - really looking forward to sharing this with our product teams as I think there is a lot of opportunity to build functionality like this for our power users. :)

A few things:

1. I use a lot of webhooks - knowing those entry and exit points is key but they aren’t included in search. I therefore write the “last element of the entry hook slug” into the Zap name. 
2. I’m planning now that every zap name is to include the name of a Jira ticket where the request, design and fault history is kept. 
3. I note that the backup contains a JSON representation of the entire setup. In theory that could be examined and broken out to create a documentation version of the setup. 
4. It’d also help if Zapier put new Zaps into a folder like (“Uncategorized”) rather than in Home

Great ideas @mrjcleaver - particularly #4!