[21 Days of Automation] Day 9: Naming conventions

21daysofautomation blogbot v 0.2 Sep 24, 2022
[21 Days of Automation] Day 9: Naming conventions

Originally posted by Blogbot on Medium on 3rdFeb 2020 

It’s essential to have naming conventions. Without them, all you are left with is either a great process/workflow/automation that’s

  • Liable to break at some point, and you’ll spend days trying to figure out why.
  • Reams of documentation that only the most patient of your team will be able to consume, leaving you with a person-shaped bottleneck

In my experience, naming conventions are the glue between process and documentation because they keep everything uniform, searchable, coordinated and re-usable. In this blog post, I wanted to cover these topics in a little more depth and share some best practices I’ve found when developing a naming convention.


Uniformity is critical for ease of reading. If you have a workflow that requires dates, for example. Make sure these are always in the same format (e.g. DD/MM/YYYY if you live in the UK, or MM/DD/YYYY if you’re from the US). Of course, uniformity is often created naturally as a by-product of automation but ensuring that it’s the bedrock of the systems and tools you are using will empower anyone else who comes to improve or edit your systems to immediately make the right decisions and connections between your steps. One example I can give from my own experience is simply numbering steps in a process, can help the user immediately understand the flow.


If you have a standard naming convention for your workflow, you’ll know what to look for across your tools. Something that I’ve found when connecting Airtable to Zapier, for example, is that it’s not always clear what fields power a zap in Airtable, which can lead to team-mates (or even your future-self) coming along and breaking everything because they simply didn’t know it would break something else. So if you ensure that your fields have as much information clearly displayed, you’ll find that people are less likely to come along and break things by accident.

By having this convention on my dependencies, I can also easily identify and search for the connected zap, and equally, within Zapier, I want to reference the field that’s powering the view, and the view itself.


Once you start a naming convention and communicate this amongst your team, you’ll find that it’s a very easy thing to maintain and keep up. As soon as you have 3 or 4 processes following the same patterns, things will begin to stick out as unusual if they don’t follow this pattern.


Finally, one of the main benefits of developing a naming convention is the inherent re-usability of your work, and thus the easier it becomes for you to maintain in the long-term. For example, if I have a naming convention for a record that consists of “Name” + “Date” + “category”, I can use this to identify records, and workflows across many of my tools, so there is no ambiguity regarding the authenticity of that record, wherever I see it.