How to Design a Scalable Tagging Strategy for Multi-Site Deployments

Overview

A tagging strategy defines what tag keys you use, what values are valid, and how tags combine to organize your deployment. Get this right and dashboards auto-populate, bulk permission assignment stays manageable, and reporting works across sites. Get it wrong and you'll spend months cleaning up inconsistencies.

Why Tagging Strategy Matters at Scale

• Tag-driven dashboards dynamically populate from a Tags watch list — no hard-coded point references
• Organization for permissions — tags do not grant roles by themselves; they group points so you can assign data-point permissions in bulk
• Reports are built from an explicit list of points, so a consistent taxonomy makes selecting the right set quick — but unlike dashboards and watch lists, a report does not pick up newly tagged points on its own
• Watch lists filtered by tags stay current as new points are added

The Three-Level Spine

Think of your tag taxonomy as a three-level spine that every data point hangs from:

1. Site — which physical location (campus, building, plant)
2. Device type — what category of equipment (RTU, generator, meter)
3. Device ID — which specific piece of equipment (RTU-01, GEN-02), as the deviceID tag

If you use Platform Manager, these three keys are fixed and must be spelled exactly: site holds the site’s Export ID (XID), deviceType the device type’s XID, and deviceID the device’s Device ID.

When every point is tagged with these three levels, tag-driven dashboards and watchlists auto-populate as new tagged devices are added — no manual dashboard editing required. Add a new RTU, tag it with the correct site, device type, and device ID, and it immediately appears in every relevant view.

The Core Tag Taxonomy

Start with these four tag keys — they cover most deployment patterns:

Extending the Taxonomy

Add keys only when you have a clear use case:

Tag Value Conventions

Consistency in tag values is more important than the values themselves:

• Case convention: Pick one (Title-Case recommended for readability) and enforce it project-wide
• Separator: Use hyphens within values: Building-A, not Building A or Building_A
• Abbreviations: Document them. RTU is ambiguous — in building and HVAC deployments it normally means "Roof Top Unit," while in utility and SCADA contexts it means "Remote Terminal Unit." Write down which one you mean so new team members aren't guessing
• No compound values: Use site=Campus-1 and building=A separately, not location=Campus1-BuildingA

Designing for Tag-Driven Dashboards

A tag-driven dashboard is a page built on a Tags watch list (Analytics > Watch list builder): each tag row selects points by key and value, either fixed or chosen by the viewer through Watch list parameters on the page. Design your tags so a single page works for any site:

• A "Site Overview" page: site chosen by the viewer, point-type=power fixed
• An "RTU Detail" page: deviceID chosen by the viewer
• A "Global Summary" page: deviceType=Generator fixed, across all sites

The tag structure determines what dashboards are possible. Plan dashboards and tags together.

Designing for Permissions

Tags are not used for permissions or roles. Use roles and data-point permissions for access control. Tags only help you find the right points when assigning those permissions in bulk:

1. Create a role per site (e.g., operator-campus-north)
2. Tag all points at that site with site=Campus-North so you can filter them quickly
3. Select the filtered points in Bulk data point edit (superadmin-only) and add the site role to View point & value
4. Set dashboard and watch list permissions to match

The tag itself never enforces access — permissions on the point (and related objects) do.

Multi-Instance vs Single-Instance Tagging

For deployments with one Mango instance per site, tags help identify data when exported or viewed centrally. For a single Mango instance managing multiple sites, tags are essential for separating data in dashboards and for bulk permission work.

Rollout Process

1. Document the taxonomy — create a reference sheet listing every tag key, allowed values, and purpose
2. Tag a pilot site — apply tags to one site and build dashboards against those tags. Validate that the taxonomy supports all required views
3. Iterate before scaling — fix any gaps discovered during the pilot. Adding a tag key later means retroactively tagging existing points
4. Bulk-tag remaining sites — use the Bulk data point edit or REST API scripts to tag at scale
5. Enforce on new devices — make tagging part of the device commissioning checklist

Common Mistakes

Summary

A scalable tagging strategy starts with the three keys Platform Manager reads — site, deviceType and deviceID — plus your own keys such as point-type, and extends only when needed. Document conventions, pilot on one site, then scale. Tags power dashboards, watch lists, and bulk selection, while permissions stay separate — getting the taxonomy right pays dividends across the entire deployment lifecycle.