Lead Tag Behaviour
Tags look simple — a coloured label on a lead profile — but they don't all behave the same way. Depending on how a tag is configured, applying it can be instant, can require a manager's approval, or can silently trigger a workflow automation. Understanding these three modes helps agents act confidently and avoid unintended consequences.
Plain labels
The default case: a tag is just an organisational label. Managers create these for everyday segmentation — "Interested in Crypto", "Callback Requested", "High Net Worth" — and agents can add or remove them at any time from the lead's profile. There is no queue, no approval, no side-effect. If a tag has no special configuration and its Is Modifiable setting is on, it's a plain label.
Approval-gated tags
Some tags are deliberately locked behind a manager sign-off. A tag becomes approval-gated when a manager turns off its Is Modifiable setting when creating or editing it.
When an agent tries to apply one of these tags, the system does not apply it immediately. Instead, it creates a Data Change Request in the manager's approval queue. The tag only appears on the lead's profile after the manager reviews and approves the request. If the manager rejects it, nothing changes on the lead.
These tags typically represent high-stakes classifications — marking a lead as a duplicate, flagging a VIP, or applying a label that affects routing or reporting downstream. The Is Modifiable lock is the mechanism that enforces "this label needs a second pair of eyes before it sticks."
From an agent's perspective: if you apply a tag and it doesn't show up immediately, look for a pending Data Change Request. The tag is waiting for approval, not lost.
Workflow-triggering tags
A tag can also be wired to a Lead Tag Workflow Config — a rule that fires an automation when the tag is applied. The most common example: applying a "Do Not Contact" or "Retired" style tag that automatically unassigns the lead from the agent and moves it to a different pool.
This is configured by managers, not agents. An agent applying such a tag may not see the workflow fire in real time, but the consequences are real — the lead may disappear from their queue moments later.
The key point: applying a tag is not always a passive act. If a tag has a workflow attached, applying it kicks off that workflow. Agents should understand which tags in their environment carry workflow effects, especially tags that look like they're just labels but actually change lead ownership or status.
Why this matters
The three behaviours exist for different purposes:
| Type | Behaviour | Typical use |
|---|---|---|
| Plain label | Applied immediately | Segmentation, notes, filters |
| Approval-gated | Queues a Data Change Request | High-stakes classifications |
| Workflow-triggering | Fires an automation on apply | Routing, unassignment, lifecycle events |
An agent who applies a tag expecting a plain label, but the tag is approval-gated, will be confused when nothing appears to happen. An agent who applies a workflow-triggering tag without realising it might find the lead gone from their queue. Neither is a bug — it's the system working as configured. Knowing the difference is what lets agents use tags correctly.
See also
- Reference: Lead Tags
- Concept: How the approval chain works
- Concept: How a lead moves through the system
- Workflow: Set up your sales process, Work a fresh lead through to first deposit