Why this matters
BI projects fail when the right people cannot see the right data at the right time. As a BI Analyst, you must map users to roles and define access needs so dashboards, semantic layers, and data models are both useful and safe.
- Real task: Decide who can view revenue by product vs. by customer.
- Real task: Separate builder roles (analysts) from consumer roles (business users).
- Real task: Apply least-privilege to protect sensitive data (e.g., HR or PII).
- Real task: Document access rules your data engineers can implement.
Concept explained simply
Identifying users, roles, and access needs means grouping people by what they do with data and specifying what each group can see and do. Think: who are they, what decisions they make, what data they need, and how sensitive it is.
Mental model
Use the R-D-A-S frame:
- Role: a job-like bucket (e.g., Sales Manager, Finance Analyst, Executive Viewer).
- Data domains: subject areas (Sales, Finance, HR, Support, Product).
- Actions: view, explore, export, build, schedule, share.
- Sensitivity: public, internal, confidential, restricted/PII.
Example questions to ask
- Which decisions do you make weekly or monthly?
- What metrics and dimensions do you rely on?
- Do you need raw data or aggregated?
- Do you need to export/share? With whom?
- Any legal or policy constraints (PII, finance close)?
Common role categories and access patterns
- Viewers: consume curated dashboards. Actions: view, filter, sometimes export aggregated data.
- Explorers: slice-and-dice within governed datasets. Actions: view, explore, save looks in personal folders.
- Creators/Analysts: build dashboards and semantic content. Actions: create, publish, schedule, manage folders.
- Admins: manage users, permissions, content lifecycle. Actions: all + governance controls.
Data sensitivity ladder (use to gate access)
- Public: safe for all employees.
- Internal: only within the company.
- Confidential: need-to-know (e.g., customer revenue at account level).
- Restricted: PII/HR/Legal—strong controls, masking, approvals.
Worked examples
Example 1: Sales Manager
- Decisions: forecast vs. quota, pipeline health, rep performance.
- Data: Opportunities, revenue, quotas, accounts (no HR or PII beyond business contact fields).
- Actions: view/explore sales dataset, export aggregated CSV, share links internally.
- Access rule: can view accounts in their region only; no customer PII details; masked emails/phones if policy requires.
Example 2: Finance Analyst
- Decisions: monthly close variance, margin analysis.
- Data: GL, invoices, cost centers; customer revenue at detailed level.
- Actions: build models and dashboards; export detailed data for reconciliation.
- Access rule: full finance domain, restricted during close; can see customer-level revenue, but not HR data.
Example 3: Executive Viewer
- Decisions: strategic trends, overall performance.
- Data: company-wide KPIs, aggregated across divisions.
- Actions: view dashboard, annotate, share snapshots.
- Access rule: broad aggregated access; no raw PII; detailed drill-down disabled to avoid accidental disclosure.
How to gather roles and access needs (step-by-step)
- List stakeholders by function: Sales, Marketing, Finance, HR, Support, Product, Execs.
- Interview or survey using the question set in the Concept section.
- Group into roles by similar decisions and actions; avoid one-off roles unless necessary.
- Map data domains each role needs and mark sensitivity per domain.
- Define actions: view, explore, build, export, schedule, share; specify where each is allowed.
- Document constraints: regional restrictions, legal/PII masking, finance close windows.
- Validate with stakeholders using a one-page role summary and sample dashboards.
- Hand off the role matrix to engineering/admins for implementation; keep it versioned.
Template: role definition snippet
Role: Sales Manager (Regional)
Decisions: Forecast accuracy, pipeline health
Data domains: Sales (opportunities, accounts), Marketing (leads - aggregated)
Actions: View, Explore, Export aggregated only, Share internal
Sensitivity: No raw PII, Mask emails/phones
Row-level rules: Region in {EMEA, AMER, APAC} based on user attribute
Red flags to watch
- Roles defined by individuals (“John’s access”) instead of responsibilities.
- Export permissions granted by default.
- Access to restricted data justified only by convenience.
- No plan for changes when people switch teams.
Common mistakes and how to self-check
- Mistake: Over-permissive access. Self-check: Is each permission tied to a decision requirement?
- Mistake: Too many bespoke roles. Self-check: Can 80% of users fit into 4–6 roles?
- Mistake: Ignoring export/share limits. Self-check: Are export rules explicit per role?
- Mistake: Missing row-level filters. Self-check: Are geographic or business-unit rules written and testable?
- Mistake: No sensitivity classification. Self-check: Did you tag each domain with a sensitivity level?
Role design checklist
- Each role has a clear purpose tied to decisions.
- Data domains and sensitivity are listed.
- Actions are explicit (view/explore/build/export/share).
- Row-level rules are concrete (attributes, regions, teams).
- PII handling is defined (masking/aggregation/deny).
- Approval and review cadence documented (e.g., quarterly).
Exercises
Exercise 1: Build a role-to-access matrix (ex1)
Use the scenario to propose roles, data domains, actions, and sensitivity controls.
Scenario
Company has Sales, Support, and Finance. Needs: Sales Managers want pipeline by region; Support Leads need ticket backlog by agent; Finance Analysts prepare monthly margin reports. Customer contact PII must be masked except for Support Leads. Exports allowed only for Finance Analysts.
Exercise 2: Write access user stories and constraints (ex2)
Translate needs into user stories and non-functional requirements.
Practical projects
- Create a one-page Access Policy for a hypothetical BI platform: 4 roles, their permissions, row-level rules, and PII handling.
- Take an existing dashboard and propose role-specific views (Viewer vs. Explorer vs. Creator), listing allowed actions per view.
- Draft a quarterly access review process: triggers, reviewers, and acceptance criteria.
Mini challenge
Given that Marketing requests raw email-level campaign data, propose a compromise that supports analysis while protecting PII. Write one paragraph and a role update.
Who this is for
- BI Analysts and Data Product Owners defining access for analytics users.
- Analytics Engineers needing clear permission specs.
- Team leads validating what their teams can see and do.
Prerequisites
- Basic understanding of your organization’s functions and data domains.
- Familiarity with BI concepts: dashboards, datasets, row-level security.
- Awareness of data privacy basics (PII, least privilege).
Learning path
- Map stakeholders and decisions.
- Draft roles using the R-D-A-S frame.
- Validate with stakeholders; iterate.
- Pilot on 1–2 dashboards; test row-level filters.
- Roll out, document, and schedule reviews.
Next steps
- Complete the exercises and compare with the provided solutions.
- Take the quick test to check understanding.
- Apply the role matrix to one real dashboard in your environment.
Progress & test
The quick test is available to everyone. If you’re logged in, your progress will be saved automatically.