Publishing, Performance, Collaboration and Governance

Introduction and context

A dashboard becomes useful only when people can access the right information at the right time and trust its meaning. Building a visualisation in Tableau Desktop or Power BI Desktop is therefore only one stage of an analytics lifecycle. The completed work must be published, connected to reliable data, refreshed, secured, monitored, improved and eventually retired.

This chapter examines that operational lifecycle. It focuses on Tableau Server or Tableau Cloud and the Power BI Service, while recognising that product features and licensing arrangements change over time. The underlying principles—controlled access, reliable refresh, efficient queries, clear ownership and documented lineage—remain applicable across platforms.

A useful distinction is between development, deployment and governance. Development concerns authoring a workbook, semantic model or report. Deployment moves that artefact into a shared environment. Governance establishes the rules that determine who may publish, view, modify, certify, share or delete it. Weak governance can make a technically attractive dashboard unsafe or misleading.

Learning objectives

By the end of this chapter, you should be able to:

• distinguish Tableau and Power BI publishing architectures;
• configure and troubleshoot refreshes and data gateways;
• design workspaces, projects, permissions and row-level security;
• identify major causes of dashboard and query-performance problems;
• use lineage, certification, ownership and lifecycle controls;
• apply a practical deployment and governance process;
• evaluate ethical, privacy and operational risks in shared analytics.

1. The analytics publishing lifecycle

A controlled publishing lifecycle commonly contains the following stages:

1. Design and development: the author prepares the data model, calculations, visual encodings and interactions.
2. Validation: data definitions, totals, filters, performance and accessibility are tested.
3. Promotion: the approved artefact is moved from a development location to a test or production location.
4. Publication: users receive access through a project, site, workspace, app or shared link.
5. Operation: scheduled or event-driven refreshes run, and failures are monitored.
6. Review: usage, quality, security and business relevance are assessed.
7. Archiving or retirement: obsolete content is removed, retained according to policy, or replaced by a successor.

This lifecycle is a control system rather than a single upload action. For example, publishing a report does not guarantee that its data will refresh, that its filters enforce security, or that a user understands the metric definitions.

A practical release record should identify the owner, business sponsor, data sources, refresh schedule, sensitivity classification, validation evidence, intended audience, support contact and planned review date. These fields reduce dependence on an individual author and make support possible when staff change roles.

2. Publishing architecture: Tableau and Power BI

Tableau Server and Tableau Cloud

A Tableau workbook may contain worksheets, dashboards, stories, data-source definitions and calculations. It can be published from Tableau Desktop or prepared through other controlled processes. In Tableau Server, the organisation operates the hosting infrastructure. It is responsible for server capacity, upgrades, authentication integration, backups and network connectivity. Tableau Cloud is a hosted service, so much of the infrastructure operation is managed by the provider, although the customer remains responsible for content, identities, permissions and data connections.

Tableau content is organised through sites, projects, workbooks, views and data sources. A project is a useful administrative boundary for related content. A workbook may contain one or more views, while a published data source can be shared by multiple workbooks. Tableau permissions are capability-based: a user or group may be allowed or denied capabilities such as viewing, filtering, downloading, commenting, editing or publishing. Effective access is determined by the combination of the user’s identity, group membership, project rules and item-level permissions. Administrators should avoid relying on informal assumptions about inheritance.

Tableau extracts are local, optimised representations of source data. They can improve interactive performance and reduce load on operational databases, but they introduce a refresh process and may contain sensitive data. A live connection queries the source during use and may provide more current information, but performance and availability depend on the source system and network.

Power BI Service

Power BI content is commonly developed in Power BI Desktop and published to the Power BI Service. A semantic model (formerly commonly called a dataset) stores the model, relationships, measures and sometimes imported data. Reports contain visual pages that use a semantic model. Dashboards in the Service are collections of pinned visualisations, and apps provide a curated distribution layer for audiences.

A workspace is a collaborative container for reports, semantic models, dashboards and related content. Workspace roles generally include Admin, Member, Contributor and Viewer, with different abilities to manage, edit or consume content. An organisation may publish an app from a workspace so that consumers see a controlled presentation rather than the entire authoring environment. As with Tableau, access should normally be assigned to groups rather than individual users, and the least-privilege principle should guide role selection.

Power BI offers Import, DirectQuery and composite approaches. Import stores data in the Power BI model and usually gives fast interactive queries, but requires refresh. DirectQuery leaves data in the source and sends queries when users interact; it can support fresher data but is more sensitive to source performance, query design and network latency. Composite models combine storage modes and require careful modelling because interactions can cross storage boundaries.

A comparison of common design choices

The products use different names and structures, but the architectural question is the same: where is data stored, when is it queried, who can change the content, and how is access enforced?

3. Refreshes, extracts and gateways

Refresh design

A refresh replaces or updates stored analytical data from its source. A schedule should reflect the business need, source-system capacity and acceptable data latency. Refreshing every hour is not automatically better than refreshing daily if the source changes daily or if frequent refreshes create avoidable operational load.

A refresh specification should state:

• the source and credentials used;
• the time zone and schedule;
• whether refresh is full, incremental or event-triggered;
• the maximum acceptable delay;
• failure notification recipients;
• treatment of late-arriving or corrected records;
• retention and recovery arrangements.

For an extract or imported model, data freshness can be described as:

Here, T_now is the current time and T_{latest\ successfully\ loaded\ record} is the timestamp of the latest record successfully loaded into the analytical store. Both values must use the same time zone or a documented conversion. This is an operational measure, not a guarantee that the source data itself is complete.

A failed refresh may result from expired credentials, a renamed column, a changed schema, unavailable network resources, gateway failure, source timeout, capacity limits or invalid transformations. A successful technical refresh can still produce an incorrect report if the source contains duplicated, incomplete or semantically changed data. Monitoring should therefore include both technical status and business-quality checks.

Gateways and private data sources

A gateway provides a secure route between a cloud analytics service and data located on a private network. In Power BI, an on-premises data gateway can support scheduled refresh and, for appropriate modes, DirectQuery connections. A gateway cluster can improve availability by allowing multiple gateway members, but clustering does not fix a bad data source or incorrect credentials. The data source definition in the Service must match the source referenced by the report or model, including server and database details where required.

Tableau Server can connect directly to sources accessible within its network. Tableau Cloud may use Tableau Bridge for selected private or on-premises data scenarios. The exact supported connection types and capabilities should be checked against the current product documentation.

Gateway practices include:

• install on a supported, stable host rather than a frequently rebooted personal computer;
• use a dedicated service identity where appropriate;
• restrict outbound and administrative access according to security policy;
• keep gateway software current;
• monitor memory, CPU, disk, connectivity and refresh duration;
• document ownership, source mappings and recovery procedures;
• avoid storing credentials in workbooks or scripts.

Incremental refresh

Incremental refresh loads only new or changed partitions rather than repeatedly processing all historical data. It is appropriate when a large table has a reliable date or change-tracking column and when historical records are relatively stable. It is not automatically suitable for tables in which old records can change without a detectable modification field.

Suppose a model contains 10 years of daily transactions but only the last 14 days can change. Processing only the mutable period can reduce refresh work substantially. However, the design must account for late-arriving transactions, deletions, corrections and time zones. A documented reconciliation process is necessary; otherwise an efficient refresh may preserve incorrect historical values.

4. Permissions, sharing and row-level security

Identity and least privilege

Authentication answers “Who is the user?” Authorisation answers “What may that user do?” These must not be confused. Single sign-on can simplify authentication, but it does not by itself define report permissions.

The least-privilege principle gives each person only the access necessary for their role. A consumer may need to view a report but not download underlying data. An analyst may need to build content from a certified source but not administer the workspace. An administrator may manage permissions but should not automatically receive unrestricted access to sensitive business data without a legitimate purpose.

Use groups, role-based access and documented ownership. Individual sharing is sometimes necessary, but it increases administration and makes reviews difficult. Sharing links should be treated as access mechanisms, not as substitutes for a permission model.

Row-level security

Row-level security (RLS) restricts the rows returned to a user. It is different from hiding a visual, applying a page filter or removing a column. A robust RLS design filters the model at the data layer and uses an identity-to-entity mapping.

For example, a security table may contain:

A relationship connects the security table to a Region dimension, which filters the fact table. In Power BI, a role can use the current user identity function (commonly represented by USERPRINCIPALNAME()) to select permitted rows. In Tableau, user filters or entitlement tables can implement a comparable pattern. The exact syntax and configuration differ by platform.

A conceptual access condition is:

where u is a user, r is a row or business entity, and Entitlement is the approved mapping between users and entities. In ordinary text this means a row is accessible when the user–row relationship exists in the entitlement data. The mapping must be maintained as carefully as the report itself.

RLS testing must use representative identities, including users with one region, several regions and no assigned region. Test both the visible rows and totals, exports, drill-through, subscriptions, alerts and connected or downstream content. A common failure is validating the report as its owner, who may have broader access than ordinary users.

RLS is not a complete information-security solution. Administrators, data-source owners and users with download or build permissions may have routes to data beyond the visual display. Sensitive information may also appear in titles, tooltips, bookmarks, cached results or exported files. Security classification and platform capabilities must therefore be considered together.

5. Performance optimisation

Performance is a user-experience, capacity and cost issue. A slow dashboard reduces adoption and encourages users to export data into uncontrolled spreadsheets. Optimisation should begin with measurement rather than guesswork.

A performance model

A simplified response-time model is:

The terms represent time waiting for capacity, transferring requests and results, executing the query, rendering the visual and performing other platform work. The equation is a diagnostic model, not a universal platform formula. Its components may overlap in real systems, and measurements should use the platform’s performance tools.

In Tableau, performance recording, workbook statistics and administrative views can help identify slow queries, expensive calculations and rendering delays. In Power BI, Performance Analyzer, model statistics, query diagnostics and capacity monitoring can identify visual query duration, DAX evaluation, DirectQuery time and rendering effects. Source-system monitoring is essential when live queries or DirectQuery are used.

Model and source optimisation

Important practices include:

• remove unused columns and rows before publication;
• select appropriate data types and avoid unnecessarily high cardinality;
• create a clear star schema with fact tables and descriptive dimensions;
• use measures rather than repeated row-level calculations when the model supports it;
• avoid bi-directional relationships unless their behaviour is clearly required;
• reduce unnecessary many-to-many ambiguity;
• aggregate data when detailed grain is not needed for the decision;
• limit expensive high-cardinality filters and excessive visual counts;
• prefer a small number of purposeful visuals to a crowded page;
• reduce unnecessary custom queries against operational systems;
• index or optimise source tables in cooperation with database specialists.

A star schema generally separates measurable events, such as sales transactions, from descriptive entities, such as date, product and store. This improves clarity and often improves query behaviour, but it does not guarantee fast performance. Poor measures, excessive data volume or a slow source can remain bottlenecks.

Visual and interaction design

Every visual can create work. A page containing many detailed tables, high-cardinality maps, complex calculations and cross-filter interactions may be slow even when each component appears reasonable in isolation. Performance-conscious design uses progressive disclosure: show key indicators first, then allow users to navigate to detail.

Avoid automatic refresh on every interaction when it is unnecessary. Use filters that reduce data early, provide meaningful default selections and avoid forcing the platform to evaluate a large unfiltered dataset. Performance should be tested on realistic devices, networks, user roles and data volumes—not only on the developer’s computer.

6. Collaboration, promotion and change management

Collaboration requires more than allowing multiple authors to edit the same content. It requires a distinction between experimental work and trusted production content.

A simple environment model is:

• Development: authors experiment with calculations, data and layouts.
• Test or validation: reviewers check totals, security, usability, accessibility and performance.
• Production: consumers receive the approved release.

Promotion may be performed through platform deployment pipelines, controlled publishing procedures or version-controlled project processes. The method should preserve a record of what changed, who approved it and when it was released. Where possible, separate credentials and permissions between development and production so that an author cannot silently bypass validation.

A change log should record changes to metric definitions, filters, source tables, RLS rules, refresh schedules and visual behaviour. Semantic changes deserve particular attention. Renaming “gross sales” to “net sales” is not merely a cosmetic change; it may invalidate comparisons and decisions.

Comments, subscriptions, alerts and shared annotations can support collaboration, but they should not become the only documentation of a critical decision. Important definitions belong in an authoritative catalogue or report description.

7. Lineage, certification and lifecycle governance

Lineage and impact analysis

Data lineage describes how data moves from an origin through transformations and semantic models to reports and users. Lineage helps answer questions such as: Which reports depend on this source? If a column changes, what may break? Which upstream system produced this figure?

Lineage is valuable for impact analysis, but it has limits. Dynamic SQL, undocumented scripts, manually uploaded files, copied workbooks and external exports may be incompletely represented. Lineage should therefore be supplemented by data-owner interviews, source inventories and testing.

Certification and endorsement

Certification or endorsement signals that an artefact has met defined standards. A certified data source or semantic model should have an accountable owner, documented definitions, reliable refresh, appropriate security and evidence of validation. Certification is not a claim that the data is perfect or suitable for every purpose; it is a statement that a governance process has been applied.

Labels should distinguish certified, reviewed, community-supported, experimental and deprecated content. A prominent badge without a meaningful review process creates false confidence.

Retention and retirement

Content accumulates quickly. Duplicate dashboards create competing numbers, confuse users and consume capacity. A lifecycle policy should define:

• criteria for active, inactive, archived and deleted content;
• minimum and maximum retention periods;
• ownership transfer when staff leave;
• review frequency based on sensitivity and business criticality;
• treatment of audit records and legal holds;
• communication and replacement arrangements before retirement.

Usage statistics can inform decisions but must not be the only criterion. A rarely viewed regulatory report may be essential, while a frequently viewed dashboard may be redundant. Retirement should include dependency checks, stakeholder notification and preservation of required evidence.

8. Ethical, legal and organisational considerations

Publishing analytics creates responsibilities concerning privacy, fairness, confidentiality and explainability. Personal data should be collected and displayed for a legitimate, defined purpose. Access should be proportionate, and sensitive attributes should not be exposed merely because the platform makes them technically available.

RLS can reduce exposure, but an analyst may infer restricted information from totals, rankings, empty categories or changes after applying filters. Small-cell disclosure is a particular risk where a dashboard reveals information about very few individuals. Aggregation thresholds, suppression, masking and careful export controls may be necessary.

Governance should also address:

• applicable privacy and records-management law;
• retention and deletion obligations;
• accessibility for users with disabilities;
• inclusive colour choices and non-colour cues;
• auditability of important decisions;
• bias in source data and metrics;
• responsible use of AI-generated calculations, summaries or narratives.

AI features can accelerate authoring and summarisation, but generated text may be inaccurate, overconfident or based on an inappropriate filter context. Human review, source attribution and restrictions on confidential prompts remain necessary. AI should assist governance, not replace accountable ownership.

9. Applied case: Northstar Retail performance reporting

The following is an illustrative case.

Background

Northstar Retail operates 180 stores and sells through an online channel. Regional managers use separate spreadsheets and several dashboards to monitor sales, margin and inventory. Executives report that “sales” differs between reports. The company also wants managers to see only their own regions.

Problem

The existing content has duplicated calculations, manually refreshed extracts and broad sharing links. One dashboard displays current online sales but a two-day-old store extract, without clearly stating the difference. Refresh failures are discovered when managers complain. A workbook owner has recently left the company.

Analysis

A governance review identifies three fact sources with inconsistent definitions. The team maps lineage from source systems to reports and finds that eight reports depend on a shared product table. Performance testing shows that a detailed transaction table is being queried for every visual, while most executive decisions require daily aggregates. Security testing reveals that a page filter hides regions visually but does not prevent an export containing all regions.

Approach and solution

Northstar creates a governed semantic model with shared Date, Product, Store and Region dimensions. A documented measure defines net sales as sales value less approved returns; the definition includes the treatment of tax and discounts. Regional entitlement data is maintained by the human-resources identity group and used for RLS. Test accounts represent regional, national and unassigned users.

The organisation establishes development, validation and production workspaces or projects. A certified production model is published through an approved release process. The private database is connected through a managed gateway or supported private-connection method, with monitored credentials and a documented owner. Historical data is incrementally refreshed where the modification date is reliable; a reconciliation report compares recent totals with the source system.

The executive report is redesigned from twelve crowded visuals to a focused summary and drill-through detail. Unused columns are removed, daily aggregates support high-level trends and detailed transactions remain available only for approved analytical needs. A refresh-status indicator states the last successful load and the source latency.

Outcome

Users receive one certified definition of net sales, regional managers see only authorised regions, and refresh failures are detected through monitoring rather than complaints. The smaller executive model responds more quickly, while detailed analysis remains available through a controlled path. The content catalogue identifies the owner, review date, lineage and replacement plan.

Learning points

1. A performance problem may originate in the model or source rather than the visual.
2. A visual filter is not equivalent to row-level security.
3. Certification requires definitions, ownership, testing and review—not merely a label.
4. Refresh reliability depends on credentials, connectivity, schema stability and data quality.
5. Lifecycle governance prevents trusted content from being overwhelmed by duplicates.

10. A practical implementation checklist

Before publishing, confirm that:

• business definitions and data grain are documented;
• source credentials use approved identities;
• the model has been tested with realistic volumes;
• refresh, time-zone and failure procedures are defined;
• RLS has been tested with representative users;
• downloads, subscriptions, drill-through and exports have been reviewed;
• workspace or project roles follow least privilege;
• the owner, steward and support route are recorded;
• lineage and dependencies are understood;
• accessibility and privacy requirements are addressed;
• certification status and review date are visible;
• a rollback or previous-version procedure exists.

After publishing, monitor refresh success, freshness, query duration, capacity, usage, permission changes and user feedback. Review the content at a defined interval and after major source, policy or organisational changes.

Challenges and limitations

Cloud services reduce infrastructure work but do not eliminate governance. Product features vary by licence, platform version, region and deployment architecture. A setting that appears secure may be undermined by export permissions, underlying-data access or administrator privileges. Automated lineage may be incomplete, and performance tools may measure different stages of a request. Finally, a technically correct dashboard can still fail if users distrust its definitions or cannot interpret its limitations.

The most durable approach is to combine platform controls with documentation, testing, accountable owners and periodic review. Governance should enable responsible use rather than create so many barriers that users bypass the official environment.

Chapter Summary

Publishing analytics is an operational lifecycle involving validation, deployment, access control, refresh, monitoring, collaboration and retirement. Tableau Server or Cloud organises content through sites, projects, workbooks, views and data sources; Power BI uses workspaces, semantic models, reports, dashboards and apps. Extracts and imported models can improve speed but require reliable refresh, whereas live and DirectQuery approaches depend more heavily on source performance.

Gateways and private-connection tools provide routes to data that is not directly accessible from a cloud service. Permissions should use groups and least privilege. Row-level security must be enforced at the data-model level and tested with realistic identities; a visual filter is not a security boundary. Performance analysis should measure queue, network, query and rendering effects, then address model, source and visual design.

Lineage supports impact analysis, certification communicates reviewed trust, and lifecycle governance controls ownership, retention, archiving and retirement. Ethical governance requires attention to privacy, inference risks, accessibility, bias, auditability and human oversight of AI-generated content. A reliable analytics environment is therefore both a technical system and an organisational control system.

Key Terms

Certification: A governance status indicating that content has passed defined review and quality controls.

Data gateway: A service that provides controlled connectivity between a cloud analytics service and private-network data.

Data lineage: The documented path from source data through transformations and models to reports and consumers.

DirectQuery: A Power BI storage approach in which queries are sent to the underlying source rather than importing all data into the model.

Extract: A stored, optimised subset or representation of source data used for analytical querying.

Import: A storage approach in which data is loaded into an analytical model for interactive use.

Least privilege: Giving a user or process only the access required for its legitimate responsibilities.

Lifecycle governance: Policies and controls governing creation, publication, review, retention, archiving and retirement.

Lineage: See data lineage; the relationships among data sources, transformations, models and outputs.

Promotion: The controlled movement of content from development or testing into production.

Refresh: The process of updating an extract, imported model or cached analytical representation from its source.

Row-level security (RLS): A control that restricts which data rows a user may retrieve.

Semantic model: A governed analytical representation containing tables, relationships, measures and business logic.

Tableau Bridge: A Tableau-supported method for connecting selected private data sources to Tableau Cloud.

Workspace: A collaborative Power BI container for reports, semantic models and related content.

Project: A Tableau organisational and administrative container for related content.

Star schema: A model design with a central fact table connected to descriptive dimension tables.

Gateway cluster: Multiple gateway members configured to improve availability and operational resilience.

Review Questions

Short Answer Questions

1. What is the difference between authentication and authorisation?
2. Why can a successful technical refresh still produce an incorrect report?
3. What is the purpose of a data gateway?
4. Why is a visual filter not a substitute for row-level security?
5. What information should a release record contain?

Long Answer Questions

1. Compare Tableau Server or Cloud with the Power BI Service in terms of content organisation, publishing and collaboration.
2. Explain how an organisation should design and monitor a refresh process for private-network data.
3. Discuss the principles of least privilege and group-based permissions in an analytics environment.
4. Explain how model design, source systems and visual composition jointly affect performance.
5. Evaluate the role of lineage, certification and lifecycle governance in maintaining trust.

Analytical / Application Questions

1. A regional dashboard hides unauthorised regions with a page filter, but users can export all underlying rows. Diagnose the control failure and propose a secure redesign.
2. A Power BI report has fast performance during development but becomes slow after publication. Develop a structured investigation using the response-time model and identify evidence you would collect.
3. A certified dataset’s source column is being renamed. Describe the lineage, testing, communication, promotion and rollback steps that should occur before the change reaches production.

Multiple Choice Questions with Answers

Question 1

Which control is specifically designed to restrict the rows returned to different users?

A. Row-level security

B. Dashboard colour formatting

C. A refresh schedule

D. A project description

Correct Answer: A. Row-level security

Question 2

What is the principal purpose of a gateway in a cloud analytics architecture?

A. To create dashboard layouts

B. To connect the cloud service to a private-network data source

C. To replace all source-system permissions

D. To certify business definitions automatically

Correct Answer: B. To connect the cloud service to a private-network data source

Question 3

Which practice best supports least-privilege administration?

A. Giving every author administrator rights

B. Sharing all reports through public links

C. Assigning role-appropriate access through groups

D. Allowing users to download every underlying table

Correct Answer: C. Assigning role-appropriate access through groups

Question 4

Which statement best describes an imported model or extract?

A. It never requires data updates

B. It stores an analytical representation that normally requires refresh

C. It always queries the source for every interaction

D. It cannot contain sensitive data

Correct Answer: B. It stores an analytical representation that normally requires refresh

Question 5

Which item is most directly supported by lineage information?

A. Identifying reports that may be affected by a source-column change

B. Guaranteeing that every metric is correct

C. Increasing network bandwidth

D. Replacing row-level security

Correct Answer: A. Identifying reports that may be affected by a source-column change

Question 6

A dashboard contains many high-cardinality tables and complex calculations. What is the most appropriate first optimisation approach?

A. Add more visuals to distribute the workload

B. Measure performance and identify the expensive queries or calculations

C. Publish it through a public link

D. Disable all user authentication

Correct Answer: B. Measure performance and identify the expensive queries or calculations

Question 7

What does certification most appropriately communicate?

A. The content can never contain an error

B. The content has passed defined review and quality controls

C. Every user may edit the content

D. The source data is always real time

Correct Answer: B. The content has passed defined review and quality controls

Question 8

Which scenario is most suitable for incremental refresh?

A. A table with no date or change-tracking field and frequent historical corrections

B. A large table where only a reliably identified recent period changes

C. A report containing only manually typed labels

D. A static image with no data source

Correct Answer: B. A large table where only a reliably identified recent period changes

Question 9

In the simplified response-time model T_total = T_queue + T_network + T_query + T_render + T_other, what does T_query represent?

A. Time spent executing the analytical query

B. Time spent assigning user permissions

C. Time spent writing governance policy

D. Time spent archiving old reports

Correct Answer: A. Time spent executing the analytical query

Question 10

Which action is most appropriate before retiring a widely used dashboard?

A. Delete it immediately without notification

B. Remove its owner and leave all links unchanged

C. Check dependencies, notify stakeholders and provide a replacement or archive path

D. Convert every visual into a public spreadsheet

Correct Answer: C. Check dependencies, notify stakeholders and provide a replacement or archive path