How do you organize your Zaps?

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 [v1]

[v2] [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.

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