Publishing and Sharing

Why this matters

Your dashboard only creates value when the right people can safely access the latest version. Publishing and sharing turn your analysis into decisions. As a Data Analyst, you will:

Real tasks youll handle

• Publish a dashboard from your BI tool to a governed workspace.
• Set viewer/editor access and row-level security for sensitive data.
• Schedule refresh and verify credentials so data stays up to date.
• Package dashboards into an app or organized project for easy discovery.
• Share with teams without creating access risks or version confusion.
• Monitor usage and adjust distribution based on adoption.

Concept explained simply

Publishing is moving your dashboard from your desktop/dev area to a secure, shared location. Sharing is deciding who can see what, where, and how they receive updates.

Mental model: The delivery pipeline

• Draft make and test your dashboard with sample data.
• Review peer-check visuals, filters, and performance.
• Publish push to a workspace/project with refresh configured.
• Share grant role-based access; apply row-level security (RLS) if needed.
• Monitor check usage, refresh health, and error logs.
• Iterate update visuals and republish versioned changes.

Core concepts and key decisions

• Audience & access: Identify viewers vs. editors. Prefer group-based permissions over individuals.
• Data refresh: Choose schedule (e.g., hourly, daily) and confirm data source credentials and gateways.
• Versioning & change management: Keep a dev/test/prod structure. Announce changes and document what changed.
• Governance & security: Use RLS, sensitivity labels/tags, and avoid public links for internal data.
• Distribution channels: Direct share, workspace/project roles, published apps/collections, email subscriptions, or approved embed.

Worked examples

Example 1: Power BI Publish to workspace and share via an app

1. In Power BI Desktop, validate filters and measure logic.
2. Click Publish and select the Prod workspace (not personal).
3. In the Power BI Service, set dataset credentials and schedule refresh (e.g., 08:00 daily).
4. Configure RLS in the dataset; map security roles to Azure AD groups.
5. Create/Update the workspace App; include the dashboard and relevant reports with descriptions.
6. Give the App access to the intended security group(s); notify stakeholders.
7. Monitor refresh history and usage metrics; fix errors promptly.

Common Power BI pitfalls

• Forgetting to map RLS roles after publishing.
• Scheduling refresh without setting gateway/credentials.
• Sharing with individuals instead of groups, causing permission drift.

Example 2: Tableau Publish to project with permissions

1. From Tableau Desktop, choose Server Publish Workbook.
2. Select the correct Project (e.g., Finance/Prod).
3. Publish data source or extract and set refresh schedule on Server/Cloud.
4. Set permissions by group: Viewers (view), Analysts (web edit if allowed), Admins (project leader).
5. Optionally configure Subscriptions for key stakeholders.
6. Test a Viewer account to confirm row-level filters behave correctly.

Common Tableau pitfalls

• Granting View but forgetting data source permissions, causing errors.
• Not documenting which filters are enforced server-side vs. user filters.

Example 3: Looker Studio (formerly Data Studio) Share with restricted access

1. Ensure the data source uses appropriate credentials (owner vs. viewer).
2. Set report sharing to Restricted, invite groups by email domain if supported.
3. Disable link-based public access for internal content.
4. Use scheduled email delivery to key viewers if needed.
5. Document the intended audience and any filters they must use.

Common Looker Studio pitfalls

• Using Anyone with the link for sensitive data.
• Misconfigured credentials yielding Data Set Configuration Error for viewers.

Hands-on exercises

Use these to practice decisions youll make when publishing dashboards. Write your answers, then compare with the solutions.

Exercise 1: Draft a publish and share plan

Scenario: You built a Sales Performance dashboard used by Sales Reps, Managers, and Executives. Data updates nightly. Reps must only see their own accounts; Managers see their team; Executives see all. Deliver a concise plan:

• Workspace/Project to publish to
• Access model (groups/roles)
• RLS rules summary
• Refresh schedule + credential owner
• Distribution channel (e.g., app/project + subscriptions)
• Adoption & monitoring checkpoints

Hints

• Favor group permissions over individuals.
• Map RLS to existing org structures (rep, manager, exec).
• Nightly data suggests a daily refresh after ETL completes.

Exercise 2: Choose a secure sharing method

Scenario: A Finance dashboard shows customer payments and includes sensitive PII. 120 internal viewers, 3 editors. Refresh every 30 minutes. Compliance forbids public links. Propose:

• How to publish (environment and packaging)
• How to grant access at scale
• Security controls (RLS, sensitivity, credentials)
• Refresh configuration and health checks

Hints

• Use an organizational app/project and security groups.
• Apply RLS and avoid publish to web or anonymous links.
• Short refresh intervals require stable gateways/credentials.

• I used groups (not individuals) for permissions.
• I included a refresh schedule and credential owner.
• I prevented public/anonymous access.
• I described RLS mapping for different roles.

Common mistakes and self-check

• Public or open links for internal data Self-check: Is sign-in required? If not, fix it.
• Individual permissions Self-check: Are at least 90% of permissions group-based?
• Unreliable refresh Self-check: Do you have alerts for failures and a named owner?
• RLS not tested Self-check: Did you view as a Rep/Manager to confirm row filters?
• Version confusion Self-check: Is there a single published app/project with change notes?

Practical projects

• Convert a personal dashboard to a production-ready, shared app/project with groups and a daily refresh.
• Implement RLS for a regional dataset; demo with three personas and screenshots of view as tests.
• Create an adoption report: usage, top users, most-used pages; propose two improvements.

Mini challenge

In one paragraph, describe how you would roll out a KPI dashboard to a 50-person support team in two phases (pilot then full launch), including how youll measure adoption and protect sensitive data.

Who this is for

• Data Analysts who need to deliver dashboards reliably to business users.
• BI Developers and Analytics Engineers formalizing production publishing.
• Team leads standardizing sharing and governance.

Prerequisites

• Working dashboard in your BI tool (Power BI, Tableau, Looker Studio, etc.).
• Access to an organizational workspace/project and security groups.
• Basic understanding of your data sources and refresh needs.

Learning path

1. Review core publishing, permissions, and RLS concepts here.
2. Complete both exercises with a real dashboard.
3. Publish to a test workspace/project; validate with a non-admin viewer account.
4. Promote to production and configure monitoring and alerts.
5. Collect feedback; iterate and document changes.

Next steps

• Set up a dev/test/prod flow and document your release checklist.
• Automate refresh failure notifications to your team channel or email group.
• Plan your next dashboard launch using the same governance model.

Quick Test

Take the short test below to check your understanding. Test is available to everyone; only logged-in users get saved progress.