Workspace roles (Viewer, Contributor, Member, Admin) and Build permission
Verdict: Consumers who must be filtered by RLS get Viewer; any higher role bypasses it. Member is the least privilege to publish an app. Build permission, separate from workspace roles, unlocks authoring new reports on a shared semantic model.
| Criterion | Viewer | Contributor | Member | Admin |
|---|---|---|---|---|
| RLS enforced on the user | Yes: RLS filters their data | No: edit rights bypass RLS | No: bypasses RLS | No: bypasses RLS |
| Publish a new app | No | No: update only, and only when delegated | Yes: least privilege to publish | Yes |
| Edit content and the semantic model | No: read and interact only | Yes | Yes | Yes |
| Manage app permissions | No | No | Yes | Yes |
Rules
- Assign report consumers the Viewer role: RLS only restricts data access for Viewers; Admins, Members and Contributors hold edit rights, so RLS roles are not evaluated for them.
- Member is the least-privileged role that can publish a new app; Contributors can update an existing app only when a workspace Admin has delegated that right.
- To let Contributors ship app updates without elevating them to Member, enable 'Allow contributors to update the app' in workspace settings; they still cannot publish the first version or change permissions.
- Build permission on a shared semantic model, not a workspace role, is what lets a user author new reports against it from a different workspace; Read alone does not.
- A semantic model surfaces in another workspace's Data hub only via workspace membership, Build permission, or residence in the analyst's My workspace.
Traps
- Promoting consumers to Contributor for convenience silently stops RLS applying to them; lock consumers to Viewer to keep RLS enforced.
- Granting Build permission does not let a Contributor publish an app; app publishing is gated on the Member role, not on Build.