Power BI Apps, Audiences a RLS

Power BI App je kurátorovaný balíček obsahu z jednoho workspace, určený pro koncové konzumenty. Uživatel vidí App, ne workspace — nemůže omylem smazat report, upravit model nebo narazit na rozpracovanou verzi.

Tím se App přímo váže na architekturu z konce kapitoly 2: konzumenti jdou přes App, tvůrci zůstávají ve workspace s rolí Contributor nebo výše.

Praktický důsledek: produkční report se v ideálním případě mění dvakrát — jednou ve workspace, kde ho vývojář upraví a otestuje, podruhé v okamžiku, kdy autor rozhodne, že je hotový, a explicitně ho publikuje do App. Mezi těmito dvěma okamžiky konzument nevidí nic — pracuje jen s poslední publikovanou verzí. Tento krok navíc funguje jako přirozená pojistka proti tomu, aby se nedokončená změna náhodou dostala před oči byznysu.

• Navigation — co uživatel uvidí v levém panelu: reporty, dashboardy, sekce, případně externí odkazy.
• Audiences — různý obsah nebo různá navigace pro různé skupiny uživatelů ze stejného workspace (viz sekce 3.4).
• Permissions — kdo má k App přístup: konkrétní e-mail, bezpečnostní skupina, nebo celá organizace.

Postup je vždy stejný: nejdřív obsah ve workspace (reporty, dashboardy), teprve pak publikace App nad tímto obsahem.

Navigation nemusí kopírovat strukturu workspace jedna k jedné — lze reporty seskupit do sekcí, přejmenovat je pro konzumenta srozumitelněji, nebo doplnit externí odkaz mimo Power BI (např. na interní wiki nebo formulář pro zpětnou vazbu). Tato vrstva kurátorství je hlavní přidaná hodnota App oproti prostému sdílení workspace — konzument dostává promyšlenou navigaci, ne technický seznam artefaktů.

Vedle klasické App existuje novější typ org apps jako samostatná položka typu Fabric item. Zásadní rozdíl je v poměru workspace : App.

Dva další praktické rozdíly oproti klasické App: uživatel s přístupem do org app vidí zahrnuté položky i při otevření přes přímý odkaz na položku, ne jen přes navigaci v App. A když uživatele z org app odeberete, org app mu zároveň automaticky odebere přístup k modelům a dalším položkám, které mu zpřístupnila — u klasické App je potřeba přístup k položkám řešit zvlášť.

Audience je skupina uživatelů se specifickým výběrem obsahu a navigace v rámci jedné App. Každá audience má vlastní seznam oprávněných uživatelů nebo skupin.

Limity se kombinují nešikovně: každý uživatel nebo skupina se počítá do celkových 10 000 za každou audience, do které je přidán. Čtyři uživatelé workspace v pěti audiences se tak počítají jako 4×5 = 20 proti celkovému limitu. Proto se v praxi vyplatí spravovat přístup přes bezpečnostní skupiny (viz kapitola 2), ne přidávat jednotlivce do více audiences zvlášť.

V pokročilém nastavení Manage audience access lze navíc povolit Allow users to share the semantic models in this app (odpovídá Share/Reshare oprávnění) a Allow users to build content with the semantic models in this app (odpovídá Build permission z kapitoly 6) — bez explicitního zapnutí těchto přepínačů uživatelé přístup k modelu navíc nezískají. Na rozdíl od zbytku audience nastavení tyto dva přepínače neplatí jen pro jednu audience, ale pro celou App najednou, včetně uživatelů, kteří k ní přistupují přes roli ve workspace. Build navíc funguje jen pro modely ve stejném workspace jako App — pro model v jiném workspace je nutné Build udělit zvlášť přímo na tom modelu.

První publikování App vyžaduje Pro licenci a roli Member ve workspace — samotný Contributor na to nestačí. Konzumenti App potřebují Pro nebo PPU licenci, pokud workspace neběží na kapacitě F64+ (pak podle pravidla z kapitoly 1 stačí Fabric Free + role Viewer/přístup k App).

• Vytvoření: Create app → nastavení navigace, audiences, permissions → Publish.
• Aktualizace obsahu: upravíte report nebo model ve workspace → krok Update app → uživatelé okamžitě vidí novou verzi.
• Uživatelé pracují vždy s obsahem publikovaným v App, ne s aktuálním rozpracovaným stavem workspace.

Krok Update app smí standardně jen Admin a Member. Admin může ve workspace settings zapnout přepínač Allow contributors to update the app for this workspace (viz kapitola 2, sekce 2.5) a delegovat aktualizaci obsahu i na Contributora — ten ale ani pak nesmí App publikovat poprvé ani měnit, kdo k ní má přístup.

Row-Level Security (RLS) filtruje data na úrovni řádků podle identity přihlášeného uživatele. Jeden sémantický model → různí uživatelé vidí různá data, ne různé reporty. Bez RLS vidí každý uživatel s přístupem k modelu všechna data.

Typické použití: regionální manažer vidí jen data svého regionu, ředitel vidí vše. Bez RLS by šlo tento rozdíl vyřešit jen duplikací reportů nebo modelů pro každou skupinu zvlášť — což znamená víc údržby, víc míst pro chybu a rozcházející se čísla mezi verzemi. RLS řeší stejný problém v jednom modelu, jednou definicí pravidla.

-- staticka RLS, role napr. "Region_West"
'Sales'[Region] = "West"

-- dynamicka RLS, role napr. "UserRegion"
-- filtr na DimUserRegion se pres vztah AllowedRegion -> Region propaguje do faktu
'DimUserRegion'[UserEmail] = USERPRINCIPALNAME()

Dynamická RLS potřebuje v modelu mapovací tabulku uživatelů, např. DimUserRegion [UserEmail, AllowedRegion]. Filtr se definuje na sloupci UserEmail proti USERPRINCIPALNAME() — samotný DimUserRegion pak musí mít vztah AllowedRegion → Region na dimenzi regionu (případně obousměrný filtr nebo bridge tabulku), aby se omezení propagovalo dál do faktové tabulky. Výhoda: nového uživatele přidáte do mapovací tabulky, ne do Power BI role. Nevýhoda: tabulka musí být aktuální — bez refreshe vidí nový uživatel prázdný report.

Dynamické funkce dostupné v DAX pro tento účel: USERPRINCIPALNAME(), USERNAME(), CUSTOMDATA().

Volba mezi statickou a dynamickou RLS je vlastně otázka škálování. U pár pevných skupin (např. tři regiony, pět poboček) je statická role rychlejší na pochopení i ladění — každá role má jednu podmínku a dá se snadno otestovat. Jakmile ale počet skupin roste do desítek nebo se mění dynamicky (noví zaměstnanci, reorganizace), statický přístup znamená neustálé přidávání a mazání rolí. Dynamická RLS s mapovací tabulkou přesune tuto správu z modelu do dat — což je udržitelnější, ale vyžaduje disciplínu v tom, aby mapovací tabulka byla vždy aktuální.

• Definice role: Power BI Desktop → Modeling → Manage roles.
• Přiřazení uživatelů: Power BI service → workspace → Semantic model → … → Security.
• Test v Desktopu: Modeling → View as → vyberte roli, případně přes „Other user“ zadejte konkrétního uživatele pro simulaci.
• Test v Service: workspace → Semantic model → … → Test as role → Now viewing as → vyberte roli, kombinaci rolí, nebo konkrétní osobu.

RLS filtruje řádky — uživatel tabulku vidí, ale jen její část. Object-Level Security (OLS) jde dál: skrývá celé tabulky nebo sloupce včetně metadat, takže uživatel objekt vůbec neuvidí ani v seznamu polí.

• Nastavuje se přes TMDL view (nově přímo v Power BI Desktop) nebo přes Tabular Editor / XMLA endpoint.
• OLS platí jen pro roli Viewer — stejně jako u RLS ji Admin, Member a Contributor obchází.
• Praktický příklad: RLS omezí data na konkrétní region, OLS zároveň skryje sloupec Salary pro uživatele mimo finanční oddělení.

• Vytváření a distribuce Power BI Apps
• Limity a omezení Power BI Apps a audiences
• End-to-end distribuce přes App
• Org apps — nová generace Power BI Apps
• Row-Level Security — přehled a nastavení
• Definice rolí a pravidel v Power BI Desktop
• Omezení dynamické RLS, včetně Test as role
• Validace rolí RLS v Power BI Desktop
• Object-Level Security (OLS)