Tags

Tags are simple string labels you attach to entities — Services, Workflows, Forms, Users, Groups, Teams, Agents, and more. They make filtering, search, and ABAC policy targeting work the way humans actually think about their data.

Open from Admin → IAM → Tags.

Why Tags

Three concrete uses:

1. Filtering & search — every list view (Services, Workflows, Inboxes, Requests) supports tag filters. Tag once, filter forever.
2. ABAC policy targeting — Policies can scope by tag (Allow read on Service WHERE tag = "PII")
3. Classification & reporting — group entities for analytics ("show MRR by tier:enterprise services")

Tag schema

Each Tag has:

• Key — the identifier (e.g. tier, region, compliance)
• Value — the value bound to a specific entity (e.g. enterprise, us-west, SOC2)
• Color — for visual scanning in lists
• Description (optional)

Tags are key-value pairs by convention but you can use bare-string tags too (just key, no value) — Nembl treats both as first-class.

Managing the tag catalog

The Tags page lists every tag definition in your Company:

• New Tag — define a new key (and optionally a default value, color, description)
• Edit — rename or recolor; reflows automatically across every entity tagged with it
• Delete — removes the tag from every tagged entity. Asks for confirmation with a count.
• Merge — combine two redundant tags into one (e.g. customer-tier:gold and tier:gold)

Applying tags

Each entity's detail page has a Tags card (per the project convention, this card sits near the bottom of the page, just above Danger Zone if any). Click Add Tag and pick from the catalog or define a new one inline. Removing a tag is a single click on its × icon.

Tag-based ABAC

In the ABAC Policy editor, conditions can reference an entity's tags:

Effect: Allow
Action: read
Resource: Service
Condition:
  resource.tags["tier"] == "enterprise"

This grants the holding principal (User / Group / Role) read on Services tagged tier:enterprise. See Policies & ABAC for the full condition syntax.

Best practices

• Use namespaced keys (tier:, region:, compliance:) so tags don't collide and stay self-documenting
• Define before sprawling — add a tag to the catalog first, then apply. Inline-tag-creation is convenient but leads to typos (enterpise, enteprise) that fragment your ABAC policies
• Delete unused tags — old tags clutter ABAC condition pickers and confuse new admins
• Don't tag everything — tag what you'll filter or police on. Universal tags (everyone is customer:true) carry no information

Related

• Policies & ABAC — tag-driven access control
• Roles & Permissions — coarser RBAC that doesn't need tags