What's changed: Created PL-300 Chapter 5, completing the textbook (domain: Manage and secure). Managing workspaces and assets (workspaces/apps, distribution, dashboards, subscriptions/alerts, promote/certify, on-premises data gateway, scheduled refresh) and security and governance (workspace roles Admin/Member/Contributor/Viewer, Build permission, row-level security RLS (static/dynamic USERNAME()), RLS group assignment, sensitivity labels).
5.2Security and governance
Understand workspace roles, item-level access, semantic model Build permission, row-level security (RLS), and sensitivity labels.
Show only the right data to the right people. Access control and row-level filtering are at the heart of Power BI security.
5.2.1Workspace roles and access
Workspace roles are development-side permissions: Admin > Member > Contributor > Viewer in decreasing power (Admin manages access; Contributor creates/edits; Viewer reads only). For post-distribution viewers, grant item-level access or app access; to let others reuse a semantic model, grant the Build permission.
5.2.2Row-level security (RLS)
Row-level security (RLS) limits which rows a user sees. In Power BI Desktop you define roles with a DAX filter expression per table (e.g., [Region] = "East"). There is static RLS (fixed conditions) and dynamic RLS using USERNAME()/USERPRINCIPALNAME() to filter by the signed-in user. In the service you assign users/groups to roles to apply it. RLS controls row visibility, a separate layer from whether someone can open the item at all (access control).
Continue reading — free sign-up
You're reading the free preview. Sign up free to read this section in full, plus every chapter (including 4+) and all questions.