Publish to the service: refresh, gateways & RLS

A .pbix on your laptop helps nobody. Publishing turns it into a shared semantic model plus a report that the sales team opens on a phone in Amravati. Here is what changes once you press Publish.

Workspaces, models, reports and apps

Object	What it is
Workspace	The container and the security boundary. Create one per team or subject area, never publish to My workspace for shared content
Semantic model	Your tables, relationships and DAX (formerly "dataset"). One model can feed many reports
Report	The pages and visuals
App	A packaged, read-only view of selected reports that you distribute to business users

Workspace roles run Admin → Member → Contributor → Viewer. Business users should be Viewers, ideally through an app; only the BI team needs Contributor or above.

Storage mode and refresh

Import mode copies data into VertiPaq — fast, but needs a refresh. DirectQuery leaves data in the source — always current, but each visual fires a query. Most FMCG sales reporting is Import with a nightly refresh.

Under Semantic model → Settings → Scheduled refresh, set the time slots and the failure-notification email. On a Pro licence you get up to 8 refreshes per day; Premium/Fabric capacity allows 48 and unlocks incremental refresh, which reloads only the last few days of invoices instead of six years.

Gateways

If the data lives anywhere the cloud cannot reach — the SQL Server in the Nagpur office, an Excel file on a shared drive — scheduled refresh fails until you install the on-premises data gateway.

• Standard mode: a Windows service on an always-on machine, shared by the team, managed centrally. Use this.
• Personal mode: tied to one person's account and machine. Fine for a prototype, a liability in production.

After installing, map each data source in the gateway and then bind it to the semantic model under Gateway connection. Sources in the cloud (SharePoint Online, Azure SQL) do not need a gateway.

Row-level security

The Amravati executive should see only Amravati stores. Define this in Power BI Desktop, under Modeling → Manage roles:

[Region] = "Vidarbha"

Static roles do not scale to 90 field executives. Use dynamic RLS instead: add a UserAccess table with Email and Region, join it so it filters Store, and write one role filter:

[Email] = USERPRINCIPALNAME ()

Test with Modeling → View as → Other user, enter a real email, and confirm the totals shrink. After publishing, assign real users or security groups to the role under Semantic model → Security.

Common mistakes

• Assuming RLS protects everyone: it is not applied to workspace Admins, Members or Contributors, who can see all rows. Put restricted users in the Viewer role or give them the app only.
• Forgetting that RLS filters rows, not columns or measures — hide sensitive columns from report view separately.
• Using a personal gateway on a laptop that goes home at 7 pm, so the 2 am refresh fails.
• Publishing over a colleague's report and wiping their layout; use deployment pipelines or Git integration for dev → test → prod.
• Storing the database password in the .pbix and never updating the credentials in the service.