GoHighLevel naming conventions

A GoHighLevel sub-account, the separate workspace that holds one client's contacts, automations and calendars, starts clean. Six months and forty workflows later, nobody can tell which one actually sends the appointment reminder. That is not a discipline problem. It is a naming problem, and it is entirely preventable.

This is the convention I apply to every build, from a three-workflow starter to a multi-location system with two hundred. It is not the only workable convention. It is a workable one, written down, applied consistently, which matters far more than which separator you picked.

Section 01Why I name things before I build them

Naming is usually treated as tidying up: you finish the build, then go back and label things properly. That never happens. The client wants it live, you move to the next task, and the name Copy of Copy of New Workflow outlives everyone involved.

So I write the name first. Deciding what a workflow is called forces me to decide what it is for, and I regularly discover at that moment that what I was about to build is really two workflows, or is a duplicate of one that already exists. The name is a design step disguised as a label.

Who actually reads these names

Three people, and only one of them is you:

• You in four months. You will remember roughly none of this. The name is a message to a stranger who happens to share your handwriting.
• The client. Non-technical clients open the workflow list far more often than you think, usually to check whether something is on. If the names are readable, you get fewer panicked messages.
• Whoever comes after you. A VA, a junior builder, another agency. Clean names are the difference between a two-hour handover and a two-week rebuild, and they are a large part of why clients come back to the person who built it properly.

What the mess costs in real terms

I have measured this on cleanups. On a sub-account with roughly sixty unnamed workflows, finding the one that sends a specific SMS takes about twenty minutes of opening and closing. On a named one, it takes under thirty seconds. Multiply by every change request for the life of the account. The convention pays for the hour it took to write down, several times over, in the first month.

The second cost is duplication. Without names, builders create a new workflow rather than search for the existing one. Duplicated automations are how contacts end up receiving the same reminder twice, the single most common complaint I get called in to fix.

Section 02The five rules behind every name

The specific format matters less than these five principles. If you take nothing else, take these.

Rule 1: The list sorts alphabetically, so make sorting do work

Workflow lists sort A–Z. That is free organisation if you put the grouping information at the front of the name, and wasted if you put it in the middle. Every related workflow should land next to its siblings without anyone dragging anything.

Two deliberate exceptions exploit the same behaviour. A leading underscore sinks or floats an item to one end of the list depending on the platform's sort; a zz- prefix reliably pushes anything to the bottom. I use zz-ARCH for retired work so it is out of the way but still recoverable.

Rule 2: One separator per level of meaning

I use exactly two separators and never mix their jobs. A hyphen joins parts within one idea (SPD-010, zz-ARCH). A pipe with spaces either side separates different ideas (SPD-010 | New Lead | Call Burst). The moment you allow three separators used interchangeably, the name stops being parseable at a glance, and stops being searchable.

Avoid slashes, commas and colons in workflow names. Commas in particular cause trouble because some GoHighLevel fields treat them as list separators. Colons are fine in tags, where I use them deliberately, but I keep them out of workflow names.

Rule 3: Describe the outcome, not the mechanism

"Send SMS 2" tells me nothing. "Rebook Push" tells me what it is trying to achieve. Write names the client could read aloud in a meeting. If a name only makes sense to someone who has the workflow open, it has failed.

• SPD-010 | Trigger | SMS + Email + TaskLists the actions. Now every workflow looks the same in the list.
• SPD-010 | New Lead | 5-Min Call BurstStates the goal. The actions can change without the name lying.

Rule 4: Leave room for what you have not built yet

Every system grows in the middle, never neatly at the end. Numbering in tens and reserving ranges (covered in section five) means the thing you did not anticipate slots in without renumbering everything after it.

Rule 5: A name in use is a contract

Some names are labels you can change freely. Others are wired into things that will break. Knowing which is which is the whole of safe renaming, and I cover the specifics in section ten. The short version: workflow names are safe to change; custom value names, the reusable placeholders you drop into messages, like the business phone number, are not, because the text of the name is what your emails reference.

Section 03The workflow naming formula

Here is the format itself. Four segments, one optional fifth.

• SPD-010 | New Lead | 5-Min Call Burst
• BOOK-030 | No Show | Rebook Push | v2
• REACT-010 | 90d Cold | Win-Back Offer | DRAFT
• OPS-020 | Daily 7am | Stale Opp Sweep

Segment 1: The system code

Three to five capital letters identifying which system this workflow belongs to. This is the most important segment because it does all the sorting and grouping work. Codes come from a fixed list (next section). The moment you invent them freely, you get BOOK, BKG and APPT all meaning the same thing.

Segment 2: The sequence number

Three digits showing roughly where this sits in the run order of its system. 010 fires before 020. This is a reading aid, not an enforcement mechanism, and nothing stops workflows running out of order, but it tells a newcomer the intended flow instantly.

Segment 3: The trigger

What starts the workflow, in three words or fewer. Not the exact GoHighLevel trigger name, but the human version: New Lead, No Show, Daily 7am, Tag Added, Stage Change. If a workflow has several triggers, name the one that matters most and record the rest in the workflow's description.

Segment 4: The outcome

What the workflow is trying to achieve, in four words or fewer. This is the segment people find hardest because it demands you know the point of the thing. Rebook Push, Value Drip, Route To Sales, Ask Review. If you cannot write this in four words, the workflow is probably doing two jobs and should be split.

Segment 5: The state flag

Left off entirely when the workflow is simply live and current. Most names should have four segments, not five. Add it only when something is true that a reader must know: v2 for a version that replaced an earlier one, DRAFT for work in progress, TEST for scratch work, HOLD for something paused deliberately.

Section 04My standard system codes

This is the fixed list I start every build from. Most accounts use eight or nine of them. The point is not that these are the correct codes. It is that the list is closed, written down, and lives in the client's account documentation.

Why three to five letters

Short enough to stay inside the character budget, long enough to be guessable without a key. SPD is memorable once you have seen it; S is not. Two-letter codes collide constantly as the account grows.

Adding a code without breaking the set

You will need a new one eventually. The test I apply: does this represent a system a client would recognise as a distinct part of their business? If yes, add it to the list and write it in the account documentation the same day. If it is really a variation of an existing system, it belongs as a sequence number under that code instead.

The failure mode here is a code used exactly once. If WEBINAR only ever labels one workflow, it is not a system. It is a workflow, and it should live under NUR or INT.

Section 05Counting in tens, with reserved ranges

Sequence numbers go 010, 020, 030, never 1, 2, 3. This is an old idea borrowed from early programming languages, and it solves exactly one problem, permanently.

Why not just count normally

Because the fourth workflow you build always belongs between the first and the second. With plain counting, inserting means renumbering everything downstream, which means updating notes, documentation, and the client's mental model. With gaps, you write 015 and move on.

Reserved ranges

000–009 is for shared sub-flows: small reusable workflows that other workflows call, like formatting a phone number or stamping a lead source. Numbering them below everything keeps them visible as foundations rather than features.

900–999 is for tests and anything on its way out. A workflow numbered in the nines is understood by everyone on the team to be non-production, which removes an entire category of accident.

Section 06Naming inside the workflow

This is where most people stop, and it is where the real time is lost. GoHighLevel lets you rename every individual step inside a workflow. Almost nobody does, so builders open a canvas and find twelve identical grey boxes labelled "If/Else", "Wait", "Send SMS".

Branches: name the condition, never the number

An if/else branch, a fork where contacts go down one path or another, defaults to names like "Branch 1". Rename it to the actual question being asked: IF · Has tag status:customer? A canvas full of named conditions can be read like a sentence.

Wait steps: always the duration and the reason

This is the single highest-value renaming habit. Every wait step gets the length and why: WAIT · 5 min, let CRM sync. Six months later, when someone asks whether they can shorten it, the answer is right there instead of requiring an archaeology session.

Prefixes I use for step types

Section 07Naming everything the workflow touches

Workflow names are half the job. A perfectly named workflow that adds a tag called Hot Lead!! has just made a mess somewhere else.

Tags: namespace them with a colon

Tags are the worst offenders in most accounts because every builder creates them on the fly and GoHighLevel stores them in lowercase. Within a year you have hot lead, hot-lead and hotlead all in use.

I namespace every tag, meaning I put a category word and a colon in front of it, so related tags group together in the dropdown:

The status: namespace comes with a rule: only one at a time. Every workflow that adds a status tag removes the previous one in the same step. Without that rule you get contacts tagged both status:lead and status:customer, and every report downstream becomes fiction.

Custom fields: the key you cannot take back

A custom field is a piece of extra information stored on a contact: roof age, fleet size, preferred branch. Each one has a visible label and a hidden key, which is the short identifier your emails use when they pull the value in.

The key is generated from the label when the field is created, and renaming the label afterwards does not update the key. So a field you rename from "Roof Age" to "Property Age" keeps a key that still says roof age, harmless but confusing forever. Name fields carefully at creation, and group them: Roofing · Roof Age, Roofing · Storm Damage.

Pipelines and stages: number the stages

Stage names appear in reports, dropdowns and workflow conditions, and not all of those respect the order you dragged them into. Prefixing with a number, so 1. New Inquiry, 2. Contacted, 3. Quoted, makes the order survive everywhere. Leave the numbering in single digits and accept that inserting a stage means renumbering; pipelines change far less often than workflows do.

Calendars, forms and funnels

Calendars: who, how long, what kind: Sales · 30 · Discovery. The duration in the name prevents the common booking mistake of sending someone to the wrong-length call.

Forms and surveys: where it lives, then what it does: Home · Free Quote, LP Roofing · Storm Damage Check. When a form's name only describes its purpose, nobody can find which page it is on.

Snapshots

A snapshot is a saved copy of an account's setup that you can load into a new client's account. These accumulate faster than anything else, and an unversioned one is a trap. Name them Niche vMajor.Minor YYYY-MM, so Roofing v2.1 2026-08. The date is what tells you, two years later, whether the snapshot predates a platform change.

Section 08Versions, drafts and archiving

The most dangerous moment in any account is editing a live workflow that contacts are currently moving through. The naming convention is what makes the safe alternative practical.

The clone-and-promote method

1. Duplicate the live workflow and append | DRAFT v2 to the copy's name.
2. Make changes in the copy, never in the original. The original keeps running.
3. Test the draft against a test contact.
4. Turn off the original, remove DRAFT from the copy's name, publish it.
5. Rename the original to zz-ARCH | [original name] v1 | [today's date].
6. Delete archived workflows after 90 days, not before.

The ninety days is not arbitrary. Problems with a changed automation usually surface within one full billing or seasonal cycle, and the archived copy is often the fastest fix.

Dates in names: always year-first

Write 2026-09-14, never 14/09/26 or Sept 14. Year-first dates sort correctly as plain text, which means your archive stays in chronological order for free. It also removes the day/month ambiguity that causes genuine confusion on international teams.

Section 09Making it stick across a team

A convention one person follows is a preference. A convention everyone follows is infrastructure. The gap between them is documentation and a recurring check.

The one-page convention document

Every account I build gets a single page pinned somewhere the team will actually find it, containing four things: the workflow formula, the closed list of system codes, the tag namespaces, and the archiving rule. One page. If it runs to three, nobody reads it and the convention dies.

Folders and names do different jobs

GoHighLevel has workflow folders, and people often ask whether folders make naming conventions unnecessary. They do not, for one reason: names travel and folders sometimes do not. Search results, dropdowns, reporting, snapshots and exports show you the name without its folder. Use both: folders for the coarse grouping you click through, names for the detail that shows up everywhere else.

Onboarding a new builder

The fastest way to transfer a convention is not the document. It is having them name three workflows before they build anything, and correcting the names. Fifteen minutes of that does more than any written spec.

Section 10Renaming a messy account without breaking it

Most of the time you are not starting clean. You have inherited eighty workflows named by four different people, some of it live and load-bearing. Here is the order I work in.

What is safe to rename

Workflows, folders, pipelines, stages, calendars, forms, trigger links and custom field labels. These are referenced internally by a hidden identifier rather than by the text you see, so changing the text does not break the connection.

What is not

Custom value names, custom field keys, and anything an outside system calls by name: Zapier or Make steps, webhooks, API integrations, spreadsheet imports mapped by column name. Renaming these is a change to an interface another system depends on, and it fails silently rather than loudly, which is what makes it dangerous.

The mapping step people skip

Step two is the one everyone wants to skip and the one that saves the project. Before touching anything: one spreadsheet row per workflow, with its current name, whether it is on, what triggers it, what it does, and its new name. You will discover in the process that roughly a quarter of the workflows do nothing, two do the same thing, and one is quietly sending texts nobody knew about. That audit is usually worth more to the client than the renaming.

Section 11The whole convention on one screen

Section 12Frequently asked questions