Sigma Version Tagging for Efficient Dashboard Management.docx

Simplify Dev, UAT, and Prod workflows, reduce errors, and streamline dashboards with Sigma version tagging.

1. Sigma Version Tagging for Efficient Dashboard Management
Simplify Dev, UAT, and Prod workflows, reduce errors, and streamline dashboards with Sigma version tagging.
In analytics and BI environments, workbooks or dashboards often go through multiple stages of
development, review, testing, and production. Without version control, promoting changes can
risk breaking dashboards for end users or cause confusion as different stakeholders see different
states of the workbook.
To address this, Sigma introduces version tagging as a lightweight, built-in version control
mechanism for workbooks and data models. Sigma Version tagging enables teams to label,
freeze, and share specific versions of a workbook or data model while still allowing further
iterative changes behind the scenes. It helps enforce stability, promote safe deployments, and
better support collaboration across development, UAT, and production workflows.
This article is based on our hands-on experience implementing Sigma version tagging in real-
world projects. Through this work, we’ve streamlined dashboard migration and environment
management, learning firsthand how tagging can eliminate manual effort, reduce errors, and
enable a structured Dev–UAT–Prod workflow for better governance and collaboration.
Our dashboard migration process is shifting from a manual, error-prone approach to a tag-based
method that is faster, consistent, and easier to manage.
In the old process, each dashboard had to be reviewed individually to identify whether it was
connected to development or production. This manual effort was time-consuming, inconsistent,
and increased the risk of errors, especially when managing a large number of dashboards.
Enhancements required duplicating dashboards, re-implementing the same changes, and
validating them multiple times, which slowed down delivery.
With the new Sigma version tagging migration, dashboards and data models can be
systematically labeled as Dev, UAT, or Prod, making it simple to filter, identify and promote
dashboards across environments. This eliminates duplicate work, reduces errors and ensures a
scalable, traceable process that supports stronger governance, better collaboration and smoother
parallel development.
Previous Approach - Manual Migration

2. Without Tag Development & UAT Workflow
1. Initial Development
a. Start development in a draft version.
Once ready, publish changes so they are visible to all users.
b. Send the dashboard/workbook to the business team for UAT (User Acceptance Testing).
2. UAT Approval / Rejection
a. If UAT is approved → Promote changes to Production by repointing
dataset/datamodel tables from Dev DB to Prod DB.
b. If UAT is not approved → Continue development in the draft version and re-follow
the same process until approved.
Handling Enhancements or Change Requests in the Production
Dashboard
1. Duplicate & Modify

3. a. Create a duplicate of the existing production dashboard/workbook.
b. Apply enhancements or changes in the draft version of this copy.
c. Publish and send it for UAT review.
2. Approval Process
a. If approved → Reapply the same changes to the main production
dashboard/workbook.
b. Republish the updated dashboard as the primary version for business use.
Key Challenge in Current Process
Repetitive Work: After UAT, the same changes must be applied twice (in the duplicated
workbook for UAT and again in the original production dashboard).
High Risk of Missed Updates: The back-and-forth between copies increases the chances of
errors, mismatched updates, or overlooked changes.
Inefficiency: Every enhancement requires duplicating, re-developing, and re-implementing
work that has already been tested once.
Proposed Tag-Based Migration Approach
Why Change?

4. Our current process results in duplicated effort and a high risk of errors:
a. After UAT, changes must be manually reapplied to both the dataset and the main
dashboard.
b. Every enhancement requires duplicating the workbook, making changes twice, and
revalidating.
c. This back-and-forth increases the chances of missed updates and delays.
How Sigma Version Tagging Works
Sigma version tagging can be applied to both datamodels and workbooks, allowing seamless
environment switching (Dev → UAT → Prod).
Tags for Both Datamodels and Workbooks
a. Tags can be applied to datamodels and workbooks, allowing seamless environment
switching (Dev → UAT → Prod).
Development Phase
a. Begin development in draft mode for both the datamodel and workbook.
b. Once changes are stable, publish them for visibility.
UAT Migration
a. Apply a UAT Tag to the published datamodel, pointing it to the UAT database instead of
the Dev database.
b. Tag the workbook to the same UAT version, ensuring the workbook automatically uses the
UAT-tagged datamodel.
c. Send the tagged workbook to the business team for UAT testing.
Production Migration (after UAT approval)
a. Re-tag the datamodel from UAT → Prod, swapping the source to the Production
database.
b. Update the workbook tag to Prod so it points to the Prod-tagged datamodel.
c. No need to reapply changes manually — Sigma version tagging handles the environment
switch.
Enhancements or New Changes
a. Future development can continue in draft/published versions in parallel, without disturbing
the Prod environment.
b. Once stable, the same Sigma version tagging process (Dev → UAT → Prod) is
followed.
Benefits of Sigma Version Tagging
Eliminates Duplicate Work → No need to reapply changes after UAT approval.
Reduces Errors → Removes manual steps, lowering risk of missed updates.
Saves Time → One development cycle covers Dev → UAT → Prod.

5. Access Control → Tags ensure business users only see Prod dashboards, while developers
work in Dev/UAT.
Parallel Development → Developers can keep working on new features without
impacting the Prod version.
Controlled Promotion → All developers can tag their work to UAT, but only authorized
admins can promote UAT changes to Prod, ensuring governance and stability.
Workbook / Workspace Sharing
We have defined three user groups with different levels of access and permissions:
1. Developer
Access Scope: All versions (Draft, Published, UAT, and Prod).
Capabilities:
a. Can develop in Draft and Published versions.
b. Can view and explore UAT and Prod tags.
c. Cannot edit UAT or Prod tags (read-only for controlled environments).
2. Explorer
Access Scope: UAT and Prod tags.

6. Capabilities:
a. Can explore data in UAT and Prod workbooks.
b. Useful for business analysts or power users who validate changes before Prod.
c. No access to Draft/Published versions.
3. Viewer
Access Scope: Prod tag only.
Capabilities:
a. Can view reports/dashboards in Prod.
b. No ability to explore or edit.
c. Designed for end business users who consume finalised dashboards.
Key Security Benefits
a. Ensures separation of duties (development, testing, production).
b. Prevents accidental edits in UAT/Prod.
c. Provides controlled visibility — Developers see everything, Explorers test, and Viewers
only consume Prod.
d. Supports parallel workflows (Dev ↔ UAT ↔ Prod) without impacting business users.
Conclusion
Sigma version tagging transforms how data analytics teams manage dashboard and data model
lifecycles. By introducing a structured, tag-based migration across Dev, UAT, and Prod
environments, it eliminates repetitive work, minimises errors, and strengthens governance. This
approach not only streamlines collaboration between developers, testers, and business users but
also ensures faster, safer, and more reliable analytics delivery.