The Power BI Service

// Publishing from Power BI Desktop
// Home tab → Publish → select workspace → Publish

// What gets published:
// 1. Report   — all pages, visuals, and formatting
// 2. Dataset  — data model: tables, relationships, measures, columns
//               NOTE: the actual data is included in Import mode
//               In DirectQuery mode, only the connection info is published

// What does NOT get published:
// - Local data sources (Excel files on your C:\ drive)
//   These must be moved to SharePoint, OneDrive, or a gateway
//   before scheduled refresh will work
// - Power Query Editor scratch queries (load disabled queries)
//   These are included but do not load data

// Re-publishing (updating an existing report):
// Publish again with the same name to the same workspace
// Power BI asks: "Replace this dataset?" → Yes
// The Report pages update
// The Dataset (data model) is replaced
// Any Dashboards built from pinned visuals update automatically
// Personal bookmarks that users saved in Service are preserved

// Publishing to "My Workspace" vs a team workspace:
// My Workspace: personal space, visible only to you
//   → not suitable for sharing with others
// Team Workspace: collaborative, controlled by workspace admins
//   → the right destination for shared reports

// Setting up scheduled refresh — in Power BI Service

// Step 1 — Configure data source credentials
// Service → Dataset → Settings → Data source credentials
// Click "Edit credentials" next to each source
// Enter username/password or OAuth as appropriate
// For local files: must use the On-premises data gateway

// Step 2 — Set the refresh schedule
// Service → Dataset → Settings → Scheduled refresh
// Toggle "Keep your data up to date" → ON
// Set frequency: Daily, Weekly, or specific days
// Add up to 8 time slots (Pro) or 48 time slots (Premium)
// Set the time zone

// Step 3 — Configure failure notifications
// "Send refresh failure notifications to" → dataset owner email
// Always enable this — silent refresh failures mean stale data
// that no one notices until an executive asks why numbers are wrong

// On-premises data gateway:
// Required when the source is a local file, SQL Server,
// or any resource not accessible from the internet
// Install on a machine that is always on
// Register with the Service under Settings → Manage gateways
// The gateway acts as a secure relay between the Service
// and your private data sources

// Step 1 — Define RLS roles in Power BI Desktop
// Modelling tab → Manage roles → New role

// Role: "North Region"
// Table: Orders
// DAX filter:  [Region] = "North"
// This role restricts Orders to North rows only

// Role: "Own Region"
// Table: Employees  (has columns: Email, Region)
// DAX filter:
[Email] = USERPRINCIPALNAME()
// USERPRINCIPALNAME() returns the email of the logged-in user
// This dynamically restricts each user to their own row in Employees
// Combined with a relationship, this flows to all related tables

// Dynamic RLS pattern — relationship-based
// Employees table: Email | Region | EmployeeID
// Orders table: EmployeeID | Revenue | ...
// Relationship: Employees[EmployeeID] → Orders[EmployeeID]
// RLS on Employees:  [Email] = USERPRINCIPALNAME()
// Result: each user sees only orders from their own EmployeeID
// No per-region roles needed — one rule handles all users

// Step 2 — Test RLS in Desktop
// Modelling tab → View as → select a role
// The report now shows only data visible to that role
// Check every page and visual to confirm correct filtering

// Step 3 — Assign users to roles in the Service
// Service → Dataset → Security
// Find the role → add user email addresses or security groups
// Users in "North Region" role see only North data
// Users in no role see all data (admins/owners bypass RLS)