Module 5 — Power BI Service & Security

The Power BI service separates content creation and collaboration from content distribution. Workspaces are primarily where teams manage Power BI items, while Apps and sharing mechanisms are how content is commonly delivered to consumers.

Workspace roles

Workspace access is controlled through four standard roles. The exact capabilities vary by role, but the exam-level distinction is important:

Use least privilege: give a person only the access needed for their task. This matters for security and because RLS behavior differs for users with elevated workspace editing permissions. A user who must consume content under RLS generally belongs in a Viewer/consumer pattern rather than being made a Contributor simply to gain access.

Apps, audiences and direct sharing

A Power BI App packages selected workspace content into a curated experience for a broader audience. Consumers do not need to become workspace collaborators just to use the App. App audiences let you expose different subsets of the App's content to different groups—for example, Finance sees finance reports while Sales sees sales reports.

App audiences control which items a user can see; they do not replace RLS, which controls which rows of data the user can see inside a report.

Direct sharing or item-level access is useful when a smaller set of users needs access to a specific report or other item. For broad, curated organizational distribution, an App is usually easier to manage.

A Power BI dashboard is a single-page canvas that exists in the Power BI service. It is intended for at-a-glance monitoring and can bring together information from supported report visuals or other tile sources. A dashboard is not the same thing as a report page in Power BI Desktop.

Tiles

The individual objects displayed on a dashboard are called tiles. A tile can be created by pinning a visual from a report or from supported Q&A content. Dashboards can also contain supported standalone tile types such as text boxes, images, web content, video or streaming-data tiles depending on the service experience.

When a report visual is pinned, the tile acts as a dashboard representation of that source visual. Selecting the tile commonly opens the underlying report or source content for deeper exploration.

Dashboard vs report

A pinned tile and its source report are related but not identical objects. For example, the tile can retain the visual type that was originally pinned even if the source report visual is later changed to another type, while refreshed data can still update what the dashboard shows.

Subscriptions and data alerts both notify users, but they are designed for different triggers. A subscription delivers content on a schedule or supported condition; a data alert notifies a user when a monitored metric crosses a threshold.

Subscriptions

A subscription sends a snapshot or link to supported Power BI report or dashboard content, typically by email. It is useful when users want a regular delivery such as a daily operations report or a weekly executive summary without having to remember to open Power BI first.

Depending on the Power BI experience and item type, subscriptions can support schedule and other delivery conditions. The central idea is that a subscription is about delivering content, not evaluating a dashboard KPI against a threshold.

Data alerts

Classic Power BI data alerts are configured on supported dashboard metric tiles such as card, KPI and gauge tiles. The alert watches refreshed dashboard data and notifies the user when the configured condition is met.

• Alerts are personal to the user who creates them; creating an alert does not automatically create the same alert for everyone who views the dashboard.
• The alert depends on the underlying data being refreshed or updated. If the semantic model never receives new values, there is nothing new for the alert to evaluate.
• Alerts are associated with supported dashboard tiles rather than being a generic alert feature for every visual on every report page.

When the Power BI service needs data that is not directly reachable from the cloud, an on-premises data gateway provides the secure connection path. Refresh and gateway questions are easier when you separate connectivity, authentication, refresh behavior and report-query behavior.

Gateway modes

The standard on-premises data gateway is intended for shared, centrally managed enterprise scenarios and can support multiple users and Power BI items. Personal mode is designed for an individual user's scenarios and has more limited administrative/sharing capabilities.

A gateway being Online means the gateway service is reachable; it does not prove that the database credentials stored for a connection are valid or that the source account still has permission to read the data.

Scheduled refresh

For an Import semantic model, scheduled refresh connects to the source, runs the configured queries and updates the model with newer data. If a refresh fails, begin with refresh history and the error details, then investigate gateway availability, credentials, source permissions, network/source availability and any schema or Power Query changes.

DirectQuery behaves differently because report interactions query the source rather than depending on a periodic full import refresh for current detailed data. However, gateway connectivity can still be required when the DirectQuery source is on premises.

Automatic page refresh

Automatic page refresh is a report-page feature that periodically refreshes supported visuals, commonly for DirectQuery monitoring scenarios. It is not the same as semantic-model scheduled refresh. Scheduled refresh reloads imported data; automatic page refresh causes a report page to query for updated results at a configured interval.

Power BI security has multiple layers. Workspace roles determine what users can do in a workspace, semantic-model permissions determine how they can use a model, and row-level security (RLS) determines which rows they can see when security is enforced.

Semantic-model permissions

• Read supports consuming content that uses the semantic model.
• Build allows users to create new reports or other supported analysis from the semantic model, including scenarios such as Analyze in Excel where available.
• Reshare allows a user to pass access to other users.

These permissions are distinct from workspace roles. If a user only needs to consume a report under RLS and create their own report from the same governed semantic model, a Viewer/consumer access pattern plus Build permission is generally more appropriate than making that person a Contributor.

Static and dynamic RLS

Static RLS uses a fixed role filter such as Region[Region] = "West". Dynamic RLS uses the signed-in user's identity to determine the permitted rows, usually through a security mapping table.

A common dynamic pattern stores one or more allowed entities against a user's UPN and filters the mapping table with USERPRINCIPALNAME(). Relationships then propagate the permitted entities to the business data.

RLS roles are defined in the model and users or groups are assigned to those roles after publishing. If a user belongs to multiple RLS roles, their permissions are generally additive: the visible rows are the union of what the roles allow rather than the intersection.

Governance features help an organization decide what content is trusted, how sensitive it is, who can access it, what depends on it, and how updates are delivered. These concepts are related but solve different problems.

RLS, OLS and hiding fields

RLS restricts rows. Object-level security (OLS) restricts access to model objects such as specific tables or columns. Simply hiding a column from the Fields pane is an authoring convenience; it does not prevent an authorized user or tool from accessing the field.

Sensitivity and endorsement

Sensitivity labels classify and protect content according to organizational information-protection policy. They are about handling sensitive information, not filtering model rows.

Promoted content is recommended or highlighted for reuse. Certified content represents a stronger organizational validation that the item is trusted and authoritative according to the organization's certification process.

Lineage, impact and usage

Lineage view and impact analysis help you understand dependencies between Power BI items and upstream/downstream assets. This is useful before changing or deleting a semantic model because you can identify reports or other items that may be affected.

Usage metrics answer adoption questions such as who is viewing a report and how often it is used. Performance Analyzer, by contrast, answers performance questions about slow visuals and queries. Query Dependencies is a Power Query view of query/source dependencies and is different from Power BI service lineage.

Publishing, updating and distributing changes

Publishing sends report and semantic-model definition changes—such as new pages, visuals, measures or relationships—to the Power BI service. A refresh updates data inside an existing model; it does not deploy new report design or DAX definitions from Desktop.

If the workspace feeds a Power BI App, changing workspace content does not always mean consumers instantly see a newly curated App experience. The App may need to be updated so the published audience receives the intended changes.

For larger controlled release processes, organizations may also use lifecycle practices such as separate development, test and production environments. Treat those as release-management concerns, distinct from basic refresh and consumer permissions.