Publishing Sharing And Access Management

Why this matters

As a BI Developer, your dashboards only create value when the right people can access them safely and reliably. Publishing, sharing, and access management are how you move from local files to enterprise-ready, governed analytics. Real tasks you will handle include:

• Publishing dashboards from development to production without breaking existing users.
• Granting least-privilege access to teams and individuals, including external clients.
• Setting up refresh schedules and credentials that survive team changes.
• Enforcing row-level security (RLS) so users see only what they should.
• Auditing usage and access to meet compliance and prove adoption.

Concept explained simply

Publishing is how you make a dashboard available in a shared workspace. Sharing is how you invite people to see it. Access management is the set of rules—roles, permissions, and security filters—that control who sees what and what they can do.

Mental model

Think of your BI environment as a building:

• The building (workspace/environment) has security guards and rules.
• Rooms (datasets, reports, dashboards) have individual locks.
• Keys (permissions/roles) grant entry to rooms and allow actions (view, edit, share).
• Frosted glass (RLS) makes sure people can only see the part of the room that’s theirs.

Core building blocks

• Workspaces / Environments: Typically Dev → Test → Prod. Keep production stable and least-privilege.
• Publishing workflow: Package content in Dev, review in Test, approve and release in Prod with change notes.
• Permissions and roles: Workspace roles (Admin, Member, Contributor, Viewer) and object permissions (View/Edit/Reshare). Use groups instead of individuals.
• Row-Level Security (RLS): Filters data based on user attributes (e.g., region). Test with test users. Avoid hardcoding emails in filters; map to roles/groups.
• Sharing methods: Workspace access, app publishing, direct sharing, email subscriptions, embed in portals. Prefer managed approaches that respect security.
• Refresh and credentials: Use service accounts/managed identities; schedule during off-peak; set failure alerts; document SLAs.
• Governance: Naming conventions, data sensitivity labels, content certification, usage/audit logs, access reviews.
• Change control: Version notes, release tags, rollback plan, deprecation notices for old content.

Worked examples

Example 1: Safe promotion to production

1. Publish dashboard to Test workspace using a test dataset.
2. Run validation: data freshness, visuals load under 3–5 seconds, RLS checks with test users.
3. Prepare release note: version, owner, risk/impact, rollback.
4. Publish to Prod and keep the dataset ID stable (avoid breaking existing links). Disable accidental re-share by limiting Contributor roles.

Example 2: Sales team sharing with RLS

1. Create RLS roles: North, South, East, West.
2. Map security table: user/group → region.
3. Assign the Sales group Viewer at workspace level and map group to RLS roles on the dataset.
4. Enable subscriptions for each regional lead. Confirm email content contains only permitted data.

Example 3: External client read-only access

1. Create a separate Client workspace/app with only the client-safe dataset and reports.
2. Apply RLS by client account ID. Disable download/export and prevent reshare.
3. Invite client users via allow-listed emails. Set access expiration and a quarterly access review reminder.

Step-by-step: Minimal viable publishing workflow

1. Prepare content: Validate measures, rename fields, add descriptions/tooltips, set default filters.
2. Wire secure data: Point to production data sources; test credentials with a service account.
3. Performance pass: Open key pages; measure load time and fix heavy visuals/filters.
4. RLS pass: Test at least three personas (full, limited, none). Document outcomes.
5. Publish to Test: Peer review visuals, definitions, and accessibility (color/contrast).
6. Approval: Stakeholder sign-off; record change note and rollback steps.
7. Publish to Prod: Set permissions for groups; schedule refresh; set alerts.
8. Announce and monitor: Notify users, share what’s new, and watch audit/usage for 1–2 weeks.

Permissions quick-reference checklist

• Use groups, not individual users.
• Viewer is the default; elevate only as needed.
• Contributors can edit content; limit to a small maintainer group.
• Admins are rare; 2–4 per workspace is typical.
• Turn off reshare for sensitive content.
• Review access quarterly; remove dormant users.
• Keep a security table for RLS mapping (user/group → scope).

Exercises

Complete the exercises below. Everyone can take them; logged-in learners get progress saved.

1. Exercise 1 — Design a promotion and access plan (mirrors Exercise ex1): Draft Dev→Test→Prod steps, roles, RLS, refresh, and rollback.
2. Exercise 2 — Implement RLS mapping (mirrors Exercise ex2): Create a simple security matrix for three users and two regions, then define filters.

Common mistakes and how to self-check

• Using personal credentials for refresh: Self-check: disable the user account in a sandbox and see if refresh fails. Fix: switch to a service account/managed identity.
• Granting edit to entire teams: Self-check: list workspace Members/Contributors. Fix: move most to Viewer; create a small Maintainers group.
• RLS gaps due to missing users: Self-check: compare security table vs. HR/group roster. Fix: add a weekly sync job or checklist before releases.
• Breaking report links on republish: Self-check: track dataset/report IDs and use replace/update flows instead of create-new. Fix: document publish steps.
• Untracked changes: Self-check: do you have version notes? Fix: add a simple change log per release.

Practical projects

• Project A: Build a two-environment pipeline (Test, Prod) with a sample sales dashboard, including RLS and scheduled refresh.
• Project B: Create a client-safe app with read-only sharing, export disabled, and an access review checklist.
• Project C: Implement usage monitoring: track top reports, inactive users, and a quarterly access review plan.

Who this is for

• BI Developers who need to ship dashboards safely to stakeholders.
• Analytics Engineers enabling governed self-serve analytics.
• Data Team Leads formalizing release and access processes.

Prerequisites

• Comfort building dashboards and datasets in a mainstream BI tool.
• Basic understanding of user groups and identity management at your company.
• Ability to test with sample user accounts or personas.

Learning path

1. Review the core building blocks and worked examples.
2. Complete Exercises 1–2 and run the publishing checklist.
3. Implement the Minimal Viable Publishing Workflow on a small, real dashboard.
4. Take the Quick Test to confirm understanding.

Mini challenge

Within one day, convert one existing ad-hoc report into a governed asset: publish to Test, add RLS for two personas, set refresh with a service account, and promote to Prod with a one-paragraph release note.

Next steps

• Standardize a workspace template (roles, naming, alerts).
• Write a one-page access policy: who gets Viewer, Contributor, Admin.
• Schedule quarterly access reviews and set calendar reminders.

Progress and test

Your Quick Test is below. Anyone can take it; if you log in, your progress will be saved.