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

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

• 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?

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.
• 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.
• 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.