Appendix B — Publishing, Securing, and Sharing Reports

The chapters of Part IV build every report in Power BI Desktop, which is free and needs no account. Organizations usually give a report to readers other than its author through the Power BI service, where it is published and shared, and publishing and sharing need a license that not every reader of this book has. Copies of the file and exported data reach readers too, with risks of their own. This appendix gathers what happens after Desktop: how a report restricts what each reader sees, how it is published and refreshed, and the ways it can be shared, with the risks of each. Desktop lets you define the security rules and test them as other users would see them, but who can open the published report, the members of each role, and the refresh are set and checked in the service.

The appendix continues the story of Chapters 15 and 16. The controller is about to give each department manager access to Charles River Reports, the package of Chapters 13 to 15, so that each can follow their own cost center against its budget. Before it goes out, internal audit, whose monitoring report Chapter 16 built, reviews who will see what.

B.1 Row-Level Security

Row-level security restricts the rows of a semantic model that each user can see. Its rules are written in DAX and grouped into roles: each rule belongs to one table and returns true or false for each row, and only the rows for which it returns true are visible to the members of the role (Microsoft, 2026f). A rule filters its table the way a slicer would, and the filter flows through active relationships to the tables on the many side, so a rule on a dimension such as CostCenter also filters the ledger and the budget lines related to it. Microsoft’s guidance is to write rules on dimension tables rather than fact tables, for that reason and for speed (Microsoft, 2024b). A table that no relationship connects to the filtered dimension is not filtered at all, a fact that matters for any page built on such a table.

A static role filters on a fixed value, such as a role named Sales whose rule keeps the cost center named Sales. A report for ten cost centers would need ten such roles, each to be kept up to date. A dynamic role filters on the identity of the person viewing the report. The DAX function USERPRINCIPALNAME returns the name the user signed in with, their user principal name, which usually looks like an email address. A rule can compare it with a security table that lists, for each user, the cost centers they may see, so that one role serves every manager and access is changed by editing the table, not the role. Roles are additive: a user in two roles sees the rows of both. Once a report with roles is published, a reader in no role sees no data at all. The rules apply only to people who read the report, never to anyone who can edit the model or who opens the .pbix file in Desktop (Microsoft, 2026f).

Row-level security secures rows. It cannot hide a table, a column, or a measure, and it cannot hide a page. A column of pay rates, for example, is hidden from a role with object-level security, which is defined in the model’s roles, in TMDL view or an external tool, and makes the column invisible to that role, as if it did not exist (Microsoft, 2026b). No setting hides a report page from one role and shows it to another. A page whose totals assume every row, such as an income statement, simply shows the rows the viewer is allowed to see, and nothing on it says the numbers are partial. Table B.1 sets out what each layer of protection covers, including the layers of the Power BI service that the second half of this appendix explains.

Table B.1: The layers that protect a Power BI report

Layer	Protects	Defined in
Row-level security	Rows of the model’s tables, by role	Power BI Desktop, Manage roles
Object-level security	Tables and columns, by role	The model’s roles, in TMDL view or an external tool
Workspace roles	Who can view, edit, publish, and share	The Power BI service
App audiences	Which items of an app each audience is shown	The Power BI service
Sensitivity labels	How content is classified, and the protection a label applies to supported exports	Microsoft Purview, applied in Desktop or the service

A security table is also a list of people with access, and access needs the same control as any other authorization. Kobelsky (2014) counts granting access, and authorizing that grant, among the duties that must be segregated in a computer-supported process, the segregation of duties of Chapter 8 applied to access itself: the person who maintains the table should not be the one who approves its entries. Least privilege, the principle that each user gets only the access the job requires, argues for a design in which a person missing from the table sees none of the protected data, rather than all of it. And the table must be reviewed. An access review compares the people who have access with the people who should have it, and its usual findings are accounts of people who have left and people whose job has changed.

Charles River’s master data shows why. The CostCenter table records a manager for each cost center, and a role built on that column would look like the natural design. But three of the ten managers of record were terminated in 2024, and none of the three was a manager: their job titles were account executive, sales representative, and inventory specialist. The managers who now run two of those departments are not recorded at all, and another department’s manager of record is an analyst. A rule built on the master data would give access to the accounts of people who left and none to the managers who need it. A security table maintained by the controller’s staff, approved by the controller, and reviewed by internal audit avoids both errors. Figure B.1 shows which tables the rules of Guided Tutorial B.1 reach.

Figure B.1: What the Security Rules Reach.

B.2 Guided Tutorial B.1: Securing the Reporting Package

Context and objective. In this tutorial, you will review and test the access the controller plans for Charles River Reports. You will start with an access review in internal audit’s monitoring file, comparing the managers recorded for each cost center with the employee records. Then you will add a security table and a dynamic role to the package, test the role as several managers would see it, and write internal audit’s findings. Internal auditors do not build the controls they audit, so in practice the controller’s staff adds the roles and internal audit tests them; in this tutorial you take both parts in turn. Everything in it is done in Power BI Desktop, with no license.

Prerequisites. You need Audit Monitoring.pbix from Chapter 16 and Charles River Reports.pbix as you left it at the end of Chapter 15. If you start here, download this tutorial’s folder from Companion Files, which holds Charles River Reports at the end of Chapter 15 and Audit Monitoring at the end of Chapter 16, and point each project at your copy of CharlesRiver.xlsx, refresh it, and save it as a .pbix file, as that page explains.

Step-by-step instructions.

Step 1. Review the managers of record.

1. In Audit Monitoring.pbix, choose Home > Get data > Excel workbook, select T75_CostCenter, click Transform Data, and rename the query CostCenterReview.
2. Keep CostCenterID, CostCenterName, and ManagerID.
3. Merge it with Employee on ManagerID and EmployeeID, and expand EmployeeName, JobTitle, EmploymentStatus, and TerminationDate without the prefix.
4. Choose Home > Close & Apply, and add a page named Access Review with a table visual of the merged columns.

Figure B.2 shows the review. Three of the ten cost centers name a terminated employee as their manager, none of whom held a manager’s job, and the department managers who now run two of them are not named anywhere. A fourth cost center names an analyst. Access built on this column would go to the wrong people, so the package needs a list of its own.

Figure B.2: The Access Review.

Step 2. Give each employee a cost center in the package.

1. Open Charles River Reports.pbix, choose Home > Transform data, and select the Employee query.
2. Click the settings icon beside the Removed Other Columns step under Applied Steps to reopen Choose Columns, select CostCenterID as well, and choose Home > Close & Apply.

The Plant page’s labor time is related to Employee, so a rule on the employee’s cost center can reach it.

Step 3. Build the security table.

1. Choose Home > Enter data, and in the Create Table dialog name two columns UserPrincipalName and CostCenterID.
2. Type the nine rows of Table B.2, leaving out its Cost center column, which is there for you to read.
3. Type Security as the table’s name, and click Load.
4. In Model view, check that no relationship line touches Security, deleting any that the file drew, and then right-click Security and choose Hide in report view.

Table B.2: The security table, as approved by the controller

UserPrincipalName	CostCenterID	Cost center
employee001@charlesriver.example	1	Executive
employee006@charlesriver.example	2	Sales
employee007@charlesriver.example	3	Warehouse
employee004@charlesriver.example	4	Manufacturing
employee010@charlesriver.example	5	Purchasing
employee005@charlesriver.example	6	Administration
employee011@charlesriver.example	7	Customer Service
employee012@charlesriver.example	9	Marketing
employee014@charlesriver.example	10	Design Services

The table is not related to anything: the rules of the next steps read it.

Step 4. Check the list against the access review.

1. Compare each address with the Email column of T74_Employee, which serves here as each user’s sign-in name, and with the Access Review page of Step 1.
2. Confirm that each address belongs to the manager the controller named for that cost center.
3. Record the cost center the list leaves out.
4. Record who maintained the list and who approved it.

The list names the managers who actually run each department, as the controller confirmed them, and each of them belongs to the cost center the list gives them. Research and Development is left out until the controller names its manager, so for now no department manager sees it, though the Finance role still does. The list was prepared by the controller’s staff and approved by the controller, so no one both grants and authorizes access, and your check in this step is internal audit’s review of it.

Step 5. Create the role and its first two rules.

1. Choose Modeling > Manage roles, click New role, and name the role Cost Center Managers.
2. Under Tables, select CostCenter, click Switch to DAX editor, and enter the first rule below.
3. Select Employee, and enter the same rule.

[CostCenterID] IN CALCULATETABLE (
    VALUES ( Security[CostCenterID] ),
    Security[UserPrincipalName] = USERPRINCIPALNAME ()
)

The rule keeps a cost center if it is among the cost centers the security table lists for the person viewing the report. On CostCenter it filters the ledger and the budget lines; on Employee it filters the labor time of the Plant page to the employees of those cost centers. Figure B.3 shows the dialog as it looks once Step 6 is done, with the rule on CostCenter open and the tables that carry a rule marked in the list.

Figure B.3: The Manage Security Roles Dialog.

Step 6. Deny everyone else, and add a role for finance.

1. Select Item, and enter the first rule below.
2. Select Security, and enter the second rule below.
3. Click New role, name it Finance, and leave it without rules.
4. Click Save.

USERPRINCIPALNAME () IN VALUES ( Security[UserPrincipalName] )

[UserPrincipalName] = USERPRINCIPALNAME ()

The invoice lines and the completions are not related to CostCenter, so without the Item rule anyone in the role would see every sale. The rule returns true for every item when the viewer is in the security table and false when the viewer is not, so a person added to the role by mistake sees no sales and no cost centers at all. The rule on Security keeps each user from reading the other users’ rows. The Finance role, for the controller and her staff, filters nothing.

Step 7. View the report as the Sales Manager.

1. Choose Modeling > View as.
2. Select Other user, type employee006@charlesriver.example, and select Cost Center Managers.
3. Click OK, and open the Budget page, the Income Statement page, the Plant page, and the Sales and Discounts page in turn.

A bar above the page names the role and the user while you view as them. The Budget page now holds one row, Sales, with the same budget, actual, and flexed budget as before, because the commission budget and the revenue budget it is flexed with both sit in the Sales cost center. The Plant page is empty. The Sales and Discounts page shows every sale, as the controller intends for listed managers. The Income Statement shows a net income more than twice the company’s, because it sets Sales’ revenue against Sales’ costs only, and nothing on the page says so.

Step 8. View the report as three more people.

1. Repeat Step 7 for employee007@charlesriver.example, the Warehouse Manager.
2. Record what the Budget and Income Statement pages show.
3. Repeat Step 7 for employee004@charlesriver.example, the Production Manager.
4. Record what the Budget and Plant pages show.
5. Repeat Step 7 for employee083@charlesriver.example, the terminated employee recorded as manager of Sales.
6. Choose Stop viewing to return to your own view.

The Warehouse Manager sees the Warehouse budget and an income statement that is a loss. The Production Manager sees the whole Plant page but an empty Budget page, because Manufacturing’s costs are budgeted as cost of goods sold, not operating expense, so the page meant for department managers does not serve this one. The former employee, absent from the security table, sees no cost center, employee, or sale, which is the deny-by-default design working. The role denies the protected data, not the whole model, though. Customer has no rule and no rule’s filter reaches it, so the segment and region slicers of the Sales and Discounts page still list every value.

Step 9. Tell readers what they are seeing.

1. Add the two measures below to the Key Measures table, each with a description, as Tutorial 15.3 gave every measure one.
2. Add a card of Cost Centers Shown to the Budget page and the Income Statement page, titled Cost centers shown.
3. Add a card of Who Am I to the About page.

Cost Centers Shown =
CONCATENATEX (
    DISTINCT ( CostCenter[CostCenterName] ),
    CostCenter[CostCenterName], ", ",
    CostCenter[CostCenterName], ASC
)

Who Am I = USERPRINCIPALNAME ()

DISTINCT leaves out the blank row that the ledger lines without a cost center would add to VALUES. Who Am I shows the name the rules compare. In the service it is the reader’s sign-in name, and in View as it is the user you typed. In Desktop without View as it is your own sign-in, which on a computer without a work account can read as the computer’s name and yours. No rule applies to you there, because roles take effect only for readers.

Step 10. Check the cards as two managers.

1. View the Budget page as the Sales Manager, as in Step 7.
2. View the Income Statement page as the Warehouse Manager.
3. Choose Stop viewing, and look at both pages again.

Viewed as a manager, the card names that manager’s cost centers, the only sign on the page that its totals are partial, as Figure B.4 shows; without a role, it lists them all. A reader who sees an unexpected name, or none of the expected cost centers, knows to ask before relying on the page.

Figure B.4: The Package Viewed as Two Managers.

Step 11. Write the findings. Write a short memo from internal audit to the controller that sets out what the review found and what you recommend.

1. Describe the managers of record and why the role does not use them.
2. Recommend who maintains the security table, who approves it, and how often internal audit reviews it.
3. Describe what each manager sees, including the pages that become partial and the Budget page that does not serve the Production Manager.
4. Save both files.

Checkpoint. Before you report to the controller, confirm the following:

• The access review lists the managers of record against the employee records, with the terminated managers visible.
• Viewed as the Sales Manager, the Budget page shows only Sales, and the card says so.
• Viewed as the terminated manager of record, the report shows no cost center, employee, or sale, while the Customer slicers still list their values.
• Your memo names the pages that a role leaves partial and who maintains, approves, and reviews the security table.

Row-level security is only as good as the list behind it and the pages it is applied to, and both are things an auditor can test before any manager opens the report.

B.3 Publishing and Sharing

A report built in Power BI Desktop usually reaches its readers through the Power BI service. Choosing Home > Publish and a workspace publishes two items, the report and the semantic model it uses, and publishing again replaces the model in the service (Microsoft, 2025b). What a person can do there depends on their license, as Table B.3 summarizes. A free license lets a person publish to their own My workspace and use what they create there, but not share it. Sharing and collaborating need a Pro or Premium Per User license, for the person who shares and, unless the workspace is on a Fabric F64 or larger capacity or a Premium capacity, for the people who view, and content in a Premium Per User workspace reaches only people who also have Premium Per User (Microsoft, 2026d). Whether you have such a license depends on your institution, which is why Guided Tutorial B.2 is optional.

Table B.3: What each license allows in the Power BI service

License	What it allows
Free	Publish to My workspace and use the content you create, without sharing it
Pro	Publish to shared workspaces and share with other Pro users
Premium Per User	The Pro capabilities and most Premium features, shared with other Premium Per User users
Capacity (Fabric F64 or higher, or Premium)	Pro and Premium Per User users share content with free users, who can view it

A workspace is a shared container in the service where a team keeps its reports and semantic models, with four roles: Admin, Member, and Contributor can create and edit content, and Viewer can only view and interact with it (Microsoft, 2025e). Row-level security does not apply to the editing roles, so department managers must never hold them. An app packages the content of a workspace for its readers, with up to 25 audiences, each of which sees the items chosen for it (Microsoft, 2026e). Audiences show and hide whole items, such as reports, not pages within a report, and they cannot take away what a workspace role grants, because anyone with a role in the workspace, a Viewer included, can open every item in it (Microsoft, 2024a). A page that should not reach managers, such as the Income Statement, therefore belongs in a separate report, built on the same semantic model and hidden from the managers’ audience, and the managers read the app without any workspace role. Row-level security applies to them there as it does to Viewers.

A published model holds a copy of the data, which must be refreshed in the service. CharlesRiver.xlsx sits on a local drive, an on-premises source, so a scheduled refresh in the service needs an on-premises data gateway, software installed on a computer that can reach the file and passes the refreshed data to the service. A workbook in OneDrive for work or school or in SharePoint can be refreshed without one, but only when the queries connect to its address in the cloud. Pointing them at a copy in a folder that OneDrive keeps in sync on the computer does not help, because they still read a file on that computer (Microsoft, 2025d). Either way, the refresh history and its failure notifications are a control. A report that silently stopped refreshing in March still shows March’s figures in June. The package’s About page states the period its data covers, and Chapter 16’s monitoring report shows the last date of each population, but only the refresh history shows when the model was last refreshed.

WarningWatch out

Publish to web creates a link that anyone on the internet can open, with no sign-in. Anyone with the link can reach all the data in the model, including rows that no visual displays, and the option does not work with row-level security at all (Microsoft, 2025c). It is meant for public data, never for financial reports, monitoring results, or anything else confidential. An administrator can turn it off for the whole organization, and an auditor reviewing a Power BI environment should check that this has been done.

Two further controls travel with the content. A sensitivity label from Microsoft Purview, applied with Sensitivity on the Home tab of Desktop, classifies a report as, for example, confidential. Applying labels requires a Pro or Premium Per User license, an organization that has enabled them and holds the Microsoft Purview Information Protection licensing they need, labels published to you, and membership in a group allowed to apply them, so a Pro or Premium Per User license alone is not enough (Microsoft, 2025a). In the service a label does not change who can open the report, which permissions alone decide. When a reader exports data on a supported path, such as to Excel, PowerPoint, or PDF, the label goes with the file, and so does any encryption the label is set to apply, but an export to .csv carries neither (Microsoft, 2025f). Sensitivity labels are not supported in Power BI projects, the .pbip format that Chapter 16 recommends for change control, so a team that needs both keeps a labeled .pbix for publishing (Microsoft, 2026c). The report’s own settings, under File > Options and settings > Options, Current File > Report settings, decide whether readers may export summarized data, the underlying data, or nothing. The administrator’s settings for the organization override them, and row-level security still limits a reader in a role to exporting the rows that reader may see (Microsoft, 2026a). Table B.4 compares the ways of sharing a report and what each risks, and Figure B.5 shows how the pieces fit together.

Table B.4: Ways to share a Power BI report and their risks

Way to share	Reaches	Main risk
The .pbix file	Anyone who gets a copy	No row-level security. Whoever can open the file in Desktop sees every row, and only a label that encrypts the file limits who can open it
A workspace role	Named people or groups	Admins, Members, and Contributors bypass row-level security, and every role opens every item in the workspace
An app with audiences	Named people or groups, as readers	Hidden items remain reachable by a direct link if hidden content is allowed, and an audience hides nothing from a workspace role
A share link	People the link names, or the organization	A link for the whole organization works for anyone there who receives it, unlike one for specific people, and recipients may reshare by default
Publish to web	Anyone on the internet	All the model’s data becomes public

Figure B.5: From Desktop to the Report’s Readers.

TipIn Practice

Row-level security can slow a report, because every query carries the role’s filters. Microsoft suggests measuring it with Performance analyzer, on the Optimize tab: record the visuals of a page without a role, then again with View as, and compare the durations (Microsoft, 2024b). Rules on dimensions, like those of Guided Tutorial B.1, are usually the more efficient design, but only repeated measurements show what a role costs, and a role that leaves fewer rows can even make a page faster.

B.4 Guided Tutorial B.2: Publishing and Sharing the Package

Context and objective. In this tutorial, you will publish Charles River Reports to the Power BI service, assign a colleague to the role of Guided Tutorial B.1, and test the role in the service, where it applies to real sign-ins rather than the names you typed in View as. Then you will complete internal audit’s memo with a recommendation on how the package should be shared.

Prerequisites. You need Charles River Reports.pbix as you left it at the end of Guided Tutorial B.1. If you start here, download Charles River Reports as it stands at the end of Guided Tutorial B.1 from Companion Files: a Power BI project that you point at your copy of CharlesRiver.xlsx, refresh, and save as Charles River Reports.pbix, as that page explains. Steps 1 to 4 need a work or school account, a shared workspace in which you are an Admin, such as a test workspace your instructor provides, and a colleague in the same organization. Each of you needs a Power BI Pro or Premium Per User license, and in a Premium Per User workspace both of you need Premium Per User. With a free license you can publish to My workspace but not share, so the roles have no one to apply to. Use an exercise workspace that your institution approves and that holds only synthetic course material. Give each pair its own workspace, or save the file under a name unique to your pair before you publish it, because republishing replaces the semantic model of the same name (Microsoft, 2025b). Your colleague must not already hold the Admin, Member, or Contributor role in the workspace or Write permission on the semantic model, directly or through a group, and must not already belong to a role of the model, such as Finance, that would change what the test shows. If you lack any of these, read Steps 1 to 4 and do Step 5, which needs none of them.

Step-by-step instructions.

Step 1. Add real sign-in names to the security table. The addresses of Table B.2 belong to Charles River’s employees, not to anyone who can sign in to your organization’s service.

1. Choose Home > Transform data, and select the Security query.
2. Under Applied Steps, click the settings icon beside the Source step to reopen the Create Table dialog.
3. Add a row with your own sign-in name and the CostCenterID 2, and a row with your colleague’s sign-in name and the CostCenterID 3.
4. Click OK, choose Home > Close & Apply, and save the report.

The security table now maps you to Sales and your colleague to Warehouse. A change to a table created with Enter data is made here, in Desktop, and published again. If anyone edits the published model in the service instead, the .pbix file on the owner’s computer no longer matches it, which is one more reason the table needs an owner and a record of each change.

Step 2. Publish the report.

1. Choose Home > Publish, and sign in if you are asked.
2. Select the exercise workspace in which you are an Admin, and click Select. If Desktop asks you to confirm replacing a semantic model, stop unless it is your own copy of this file.
3. Open the link that Power BI Desktop shows when publishing succeeds.

Publishing puts two items in the workspace, the report and the semantic model, both named after the file. The roles travel inside the model, but their members do not: in the service, the role has no one in it yet. A free license lets you publish only to My workspace, where nothing can be shared.

Step 3. Assign the role and test it as yourself.

1. In the workspace, open the More options (…) menu of the semantic model, and choose Security.
2. Select Cost Center Managers, add yourself and your colleague as members, and save the change.
3. Choose More options (…) next to the role, and then Test as role.
4. Open the Budget page and the About page.
5. Choose Back to Row-Level Security.

The header names the role and the person it is applied as, and the report shows Sales only, with your sign-in name on the Who Am I card. Test as role can also be set to view as a specific person, but Microsoft cautions that it evaluates dynamic rules with your own identity (Microsoft, 2026f). The Who Am I card shows which name the rules compared, and only your colleague, signed in, shows for certain what your colleague sees. As an Admin of the workspace, you see every row when you open the report normally, because row-level security does not apply to the editing roles.

Step 4. Test with your colleague, then remove the test access.

1. In the workspace, choose Manage access, write down who already has access and through which role or group, and then choose Add people or groups.
2. Add your colleague with the Viewer role, and select Add.
3. Ask your colleague to sign in again, and to open the report and its Budget and About pages.
4. Record what your colleague sees, and the name on the Who Am I card.
5. Using your record from step a, remove only what this test added: your colleague’s workspace access, and the two memberships of Cost Center Managers under the semantic model’s Security, yours and your colleague’s. Keep any access that was already there, and if it comes through a group, or you cannot restore it safely, ask your instructor to finish the cleanup.
6. In Desktop, delete the two rows you added in Step 1, choose Home > Close & Apply, and publish again to the same workspace.
7. Ask your colleague to sign in again, and confirm that the report opens only if your record from step a shows access that was already there. Record any other access that still opens it.

Your colleague, a Viewer, sees only Warehouse, with the colleague’s sign-in name on the Who Am I card. If your colleague sees every row instead, another grant, such as a higher workspace role, access through a group, or the Finance role, is in play, and your record from step a shows where to look. Workspace access, role membership, and the rows of the security table are separate grants, so the test ends by removing each one it created and leaving what was there before.

Step 5. Recommend how the package is shared. Add a section to internal audit’s memo of Guided Tutorial B.1. The Viewer role of Step 4 served the test, not the design the memo recommends.

1. Recommend how the department managers reach the package, through the app or a workspace role, and the workspace role of the controller’s staff who maintain it. Say which app settings you would allow, keeping Access to hidden content off and granting sharing and Build permission only for a need the controller documents (Microsoft, 2026e), and how internal audit will check what an approved manager can open and see.
2. Recommend where the Income Statement and Validation pages belong, given that row-level security cannot hide a page and app audiences show whole reports.
3. Recommend how the semantic model is refreshed, and who watches the refresh history.
4. Recommend whether Publish to web should be allowed, and whether the package should carry a sensitivity label.

Checkpoint. Before you send the memo, confirm the following:

• Your results were recorded while the test access was in place. Then only the temporary grants were removed (your colleague’s workspace access, both role memberships, and the two test rows), the report was published again, and the access that remains matches your initial record.
• Testing as the role shows Sales for you, your colleague sees Warehouse, or, without a license, your memo explains what each test would show.
• The memo recommends how each kind of reader reaches the package, a home for the finance pages, a refresh owner, and a position on Publish to web and labels.

Publishing moves the report from a file you control to a service many people reach, and every way of sharing it either keeps the rules of Guided Tutorial B.1 in force or quietly bypasses them.

B.5 Key Terms

Access review. A periodic comparison of the people who have access to a system or report with the people who should have it, approved by someone other than the person who maintains the access. Its usual findings are accounts of people who have left and access that no longer matches a person’s job.

App. In the Power BI service, a package of the reports and dashboards of one workspace published to readers, who can view and interact with it but not change it. An app can have several audiences, each shown a different selection of its content, though anyone with a workspace role sees all of it.

Least privilege. The principle that each user receives only the access their job requires, so that a person missing from an access list is denied the protected data rather than given all of it.

Object-level security. Power BI security that hides tables or columns of a semantic model from the members of a role, as if those objects did not exist. It is defined in the model’s roles, in TMDL view or an external tool, and visuals that use a hidden column fail for the role.

On-premises data gateway. Software, installed on a computer that can reach a data source the service cannot reach directly, such as a workbook on a local drive, through which the Power BI service refreshes a semantic model from that source.

Publish to web. A Power BI service option that creates a public link to a report, viewable by anyone on the internet without signing in. It exposes all the data in the model and is not supported with row-level security, so it is never used for confidential data.

Row-level security. Power BI security that restricts which rows of a semantic model each user can see, through roles whose DAX rules return true or false for each row of a table. A rule’s filter flows through active relationships to the tables on their many side, and the rules apply to the readers of a report, not to the editors of its workspace.

Security role. A named set of row-level or object-level security rules in a semantic model. A static role filters on fixed values, and a dynamic role filters on the identity of the viewer, typically by comparing USERPRINCIPALNAME with a security table. A user in several roles sees the rows of all of them.

Sensitivity label. A classification from Microsoft Purview, such as Confidential, applied to Power BI content. The label travels with data exported on supported paths, such as to Excel, PowerPoint, or PDF, with any encryption it is set to apply, while access within the service is decided by permissions.

User principal name. The name a person signs in with in Microsoft’s cloud services, which usually looks like an email address. The DAX function USERPRINCIPALNAME returns it, and dynamic security roles compare it with a security table.

Workspace. A shared container in the Power BI service where a team keeps reports and semantic models. Its roles are Admin, Member, Contributor, and Viewer. Of the four, only Viewers are subject to row-level security, and every role can open every item in the workspace.

B.6 Multiple Choice Questions

1. A role has one rule, on the CostCenter table. Which rows does it restrict?

1. The rows of every table in the semantic model
2. Only the rows of the CostCenter table itself
3. The rows of any table that has a column named CostCenterID
4. CostCenter and the tables its active relationships reach

2. The controller adds a department manager to the workspace as a Member, so that the manager can open the package. What will the manager see?

1. Only the rows of the manager’s own cost center
2. Every row, because the rules do not apply to Members
3. Nothing, until the manager is added to a security role
4. Only the pages that the app audience includes

3. Why should the dynamic role not be built on the ManagerID column of Charles River’s CostCenter table?

1. The column holds names rather than the identifiers a rule needs
2. USERPRINCIPALNAME cannot be compared with a number
3. It names terminated employees and omits current managers
4. A role may not read a column of a dimension table

4. The role in Guided Tutorial B.1 has a rule on Item: USERPRINCIPALNAME () IN VALUES ( Security[UserPrincipalName] ). What is it for?

1. It hides the items of other cost centers from each manager
2. It speeds up the role by filtering the largest table in the model
3. It lets the Finance role see every item
4. It shows no sales to anyone missing from the security table

5. Internal audit wants the column of hourly pay rates hidden from department managers while they still see the hours. Which feature does that?

1. Object-level security
2. Row-level security
3. A sensitivity label
4. An app audience for managers

6. When is Publish to web appropriate for a Charles River report?

1. When the readers cannot get a Power BI license
2. When the report uses row-level security
3. When the data may be made public
4. When the report is a monitoring page

7. The package is published from a file that reads CharlesRiver.xlsx on a local drive. What does a scheduled refresh in the Power BI service need?

1. An on-premises data gateway that can reach the file
2. A Premium Per User license for each reader of the report
3. A sensitivity label on the semantic model
4. A row-level security role for the refresh

8. Viewed as a department manager, the Income Statement page shows only that cost center’s rows and nothing on it says so. Which response fits the recommendations of this appendix?

1. Hide the page so that it no longer appears among the page tabs of the report
2. Move it to a separate report for finance, and label what each manager sees
3. Add an object-level security rule to the Income Statement page
4. Remove the CostCenter rule so that managers see the whole ledger

B.7 Applied Exercises

Work on both exercises in a copy of Charles River Reports.pbix, saved with File > Save as after you finish Guided Tutorial B.1, such as Security Exercises.pbix. Build each exercise on its own report page, or in its own query tab in DAX query view, named after it (such as Ex B.1). Do not change the queries, relationships, measures, roles, or pages the tutorials created, except where an exercise asks you to extend the role. When an exercise needs a Table the tutorials did not load, import it under the query name the exercise gives. Neither exercise needs a license. Hand in the saved .pbix with each deliverable, together with a short test log of every View as test, naming the role, the user, the filters, what you expected, and what you saw. Screenshots can support the log, but they do not replace the file.

B.7.1 Managerial Accounting Exercises

Exercise B.1: Securing Pay Data

Table group: Payroll and Time

Scenario. After Guided Tutorial B.1, the controller asks whether department managers could see what individual employees are paid. LaborTimeEntry carries the cost of each line of labor time, and the production manager, who does see the plant’s employees, should see their hours but not their pay.

Requirements.

1. Add a measure Labor Cost, the sum of LaborTimeEntry[ExtendedLaborCost], and a page Ex B.1 with a table visual of Manufacturing Hours and Labor Cost by JobTitle for 2026 and, below it, a separate card of Labor Cost, also for 2026.

2. In TMDL view, script the Cost Center Managers role by dragging it from the Model tab of the Data pane into a new script tab. Add a column permission that sets the metadata permission of ExtendedLaborCost to none, written as Microsoft’s page on object-level security shows (Microsoft, 2026b), and keep the role’s four row rules, on CostCenter, Employee, Item, and Security. Choose Preview, confirm that the rules are still there, and then choose Apply.

3. View the report as the Production Manager with View as, and record what happens to the table and the card of requirement (1) and to the Plant page. View it with the Finance role and compare.

4. On the Optimize tab, open Performance analyzer, record the visuals of the Budget page without a role and then with View as, and compare the durations.

5. Explain why object-level security, not row-level security, is the right tool for this requirement, and what the controller should do about visuals that fail for the role.

Deliverable. The saved .pbix, the role’s script, the test log with the Performance analyzer comparison, and a short note answering requirement (5).

B.7.2 Auditing Exercises

Exercise B.2: Reviewing Access with a Query

Table group: Organizational Planning, with the Employee table from Master Data

Scenario. Guided Tutorial B.1 checked the security table by eye. Internal audit wants the review as a query it can run every quarter, so that the security table is tested against the employee records each time it changes.

Requirements.

1. Import T74_Employee as AccessEmployees, keeping EmployeeID, EmployeeName, Email, JobTitle, CostCenterID, EmploymentStatus, and TerminationDate. Leave it unrelated to the other tables, and check in Model view that no relationship line touches it.

2. In DAX query view, in a query tab named Ex B.2, write a query that lists the cost centers with no row in the security table, by name.

3. Add a query that lists the users mapped to more than one cost center.

4. Add a query that returns one row per user in the security table, with the employee whose Email matches the user’s name, that employee’s job title, status, termination date, and own cost center, and a column that flags users who match no employee, who are terminated, or who are mapped to a cost center other than their own.

5. The role of Guided Tutorial B.1 has no rule on AccessEmployees. On the page Ex B.2, add a table visual of AccessEmployees, view the report as the Sales Manager, and find out what a manager in the role could see of the new table.

6. Explain what the queries found, how often internal audit should run them, and what to do about AccessEmployees before the file is published.

Deliverable. The saved .pbix with the query tab, the test log of requirement (5), and a short note answering requirements (5) and (6).

B.8 References

Kobelsky, K. W. (2014). A conceptual model for segregation of duties: Integrating theory and practice for manual and IT-supported processes. International Journal of Accounting Information Systems, 15(4), 304–322. https://doi.org/10.1016/j.accinf.2014.05.003

Microsoft. (2024a). Power BI implementation planning: Report consumer security planning. Microsoft Learn. https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-implementation-planning-security-report-consumer-planning

Microsoft. (2024b). Row-level security (RLS) guidance in Power BI Desktop. Microsoft Learn. https://learn.microsoft.com/en-us/power-bi/guidance/rls-guidance

Microsoft. (2025a). How to apply sensitivity labels in Power BI. Microsoft Learn. https://learn.microsoft.com/en-us/fabric/enterprise/powerbi/service-security-apply-data-sensitivity-labels

Microsoft. (2025b). Publish from Power BI Desktop. Microsoft Learn. https://learn.microsoft.com/en-us/power-bi/create-reports/desktop-upload-desktop-files

Microsoft. (2025c). Publish to web from Power BI. Microsoft Learn. https://learn.microsoft.com/en-us/power-bi/collaborate-share/service-publish-to-web

Microsoft. (2025d). Refresh a semantic model created from an Excel workbook - cloud. Microsoft Learn. https://learn.microsoft.com/en-us/power-bi/connect-data/refresh-excel-file-onedrive

Microsoft. (2025e). Roles in workspaces in Power BI. Microsoft Learn. https://learn.microsoft.com/en-us/power-bi/collaborate-share/service-roles-new-workspaces

Microsoft. (2025f). Sensitivity labels in Power BI. Microsoft Learn. https://learn.microsoft.com/en-us/fabric/enterprise/powerbi/service-security-sensitivity-label-overview

Microsoft. (2026a). Export data from a Power BI visualization. Microsoft Learn. https://learn.microsoft.com/en-us/power-bi/visuals/power-bi-visualization-export-data

Microsoft. (2026b). Object-level security (OLS) with Power BI. Microsoft Learn. https://learn.microsoft.com/en-us/fabric/security/service-admin-object-level-security

Microsoft. (2026c). Power BI Desktop projects (PBIP). Microsoft Learn. https://learn.microsoft.com/en-us/power-bi/developer/projects/projects-overview

Microsoft. (2026d). Power BI service features by license type. Microsoft Learn. https://learn.microsoft.com/en-us/power-bi/fundamentals/service-features-license-type

Microsoft. (2026e). Publish a workspace app in Power BI. Microsoft Learn. https://learn.microsoft.com/en-us/power-bi/collaborate-share/service-create-distribute-apps

Microsoft. (2026f). Row-level security (RLS) with Power BI. Microsoft Learn. https://learn.microsoft.com/en-us/fabric/security/service-admin-row-level-security