Sdílené pracovní prostory

Workspace není jen složka pro uspořádání souborů — je to hranice přístupu, správy a nasazení. Kdo má roli ve workspace, vidí (nebo spravuje) vše, co v něm je. Kapacita, ke které je workspace přiřazen, určuje výkon a dostupné funkce pro všechen obsah uvnitř.

Kdo čeká, že role ve workspace budou jen kosmetické nastavení viditelnosti, narazí rychle — role určuje i to, kdo smí publikovat, kdo smí model přepsat a kdo smí workspace smazat. Proto se v produkčním prostředí vyplatí návrh rolí a organizace workspace řešit ještě předtím, než vznikne první sémantický model, ne až dodatečně.

Stejná hranice platí i pro nasazení: Deployment Pipelines (kapitola 5) pracují vždy mezi workspace, nikdy mezi jednotlivými položkami. Pokud workspace obsahuje zbytečně široký mix obsahu z různých domén, propaguje se celý tento mix najednou — což je další důvod, proč organizaci workspace neřešit ad hoc.

V praxi je My workspace ideální pro rychlé prototypování — vyzkoušet nový vizuál, otestovat DAX míru, ověřit, že se data z nového zdroje načítají správně. Jakmile má obsah přejít k dalšímu člověku, ať už ke schválení nebo ke sdílení, patří do sdíleného workspace. Přesun existujícího reportu z My workspace do sdíleného workspace navíc není vždy triviální — jednodušší je rovnou pracovat na správném místě, jakmile je jasné, že výstup má přesah mimo jednoho autora.

Workspace je jednotka nasazení, takže jejich členění přímo ovlivňuje, jak snadno se bude obsah spravovat a nasazovat dál. Tři typické strategie:

• Podle prostředí — DEV / TEST / PROD, přirozeně navazuje na Deployment Pipelines (kapitola 5).
• Podle týmu nebo oddělení — Finance, HR, Obchod; odpovídá organizační struktuře a vlastnictví dat.
• Kombinace — např. Finance-DEV, Finance-PROD; nejčastější volba ve větších organizacích.

Jeden tým může spravovat více workspace, ale jeden workspace by měl mít jasného vlastníka — bez toho se řízení přístupu rychle rozpadne na „kdo tam dal koho a proč“.

Volba strategie by měla vycházet z toho, kdo skutečně vlastní data a kdo o nich rozhoduje, ne z toho, jak je to technicky nejrychlejší nastavit. Organizace podle prostředí (DEV/TEST/PROD) dává smysl tam, kde existuje jasný proces uvolňování změn a kde se plánuje využít Deployment Pipelines. Organizace podle týmu nebo domény naopak odpovídá tomu, jak firma přirozeně vlastní a spravuje svá data — a bývá přirozenější pro menší týmy, které si vystačí s jedním prostředím. Kombinace obojího je nejnáročnější na správu, ale škáluje nejlépe pro organizace s více týmy a formálním release procesem.

Workspace bez přiřazené kapacity běží na shared capacity — s omezením velikosti modelu, výkonu a frekvence refreshe (viz kapitola 1). Po přiřazení F-SKU (nebo P-SKU) kapacity workspace získá:

• podporu pro Deployment Pipelines,
• větší limity velikosti modelu,
• možnost vytvářet další Fabric položky — Lakehouse, Warehouse, Notebook,
• dostupnost pro konzumenty bez Pro licence (podle hranice F64 z kapitoly 1).

Workspace na kapacitě se v uživatelském rozhraní pozná podle diamantové ikony 💎 u jeho názvu.

Přiřadit workspace ke kapacitě smí workspace Admin, který má zároveň na dané kapacitě přidělenou roli Contributor (nebo je jejím capacity adminem) — Contributor na kapacitě smí workspace do kapacity přiřadit, ale nesmí měnit nastavení kapacity ani ji mazat. Nejde tedy nutně o zásah Fabric Administrátora nad celým tenantem; podrobnosti o rolích nad kapacitou přináší kapitola 7. Vlastník workspace by přesto měl vědět, na jaké kapacitě jeho obsah běží — ovlivňuje to nejen výkon, ale i to, jaké funkce jsou v tom kterém workspace vůbec dostupné k použití. Přechod ze shared capacity na F-SKU je vratná operace, přesto ale znamená, že se mění chování produkčního obsahu, takže patří mezi změny, které je vhodné naplánovat a otestovat, ne provést bez upozornění.

Role ve workspace jsou vnořené — Admin obsahuje oprávnění Member, Member obsahuje oprávnění Contributor, Contributor obsahuje oprávnění Viewer. Nejde o čtyři nezávislé sady práv, ale o narůstající škálu.

Publikovat App poprvé a měnit její oprávnění smí jen Admin a Member. Contributor může App jen aktualizovat — a to pouze pokud Admin ve workspace settings zapne přepínač Allow contributors to update the app for this workspace. I pak Contributor nesmí vytvořit novou App ani upravovat, kdo k ní má přístup.

Contributor může publikovat a přepsat existující report nebo model, ale nemůže přidávat další lidi do workspace ani měnit jeho nastavení či ho smazat. Typické použití: vývojáři, kteří publikují obsah, ale nemají na starosti správu prostoru.

V praxi to znamená, že delegace přístupu do produkčního workspace jde bezpečně svěřit i Memberovi, aniž by musel mít plná administrátorská práva nad kapacitou nebo nastavením workspace. Pro tým, kde je Admin jen jeden a zbytek jsou Member, to zjednodušuje onboarding nových lidí — nečeká se na jedinou osobu s nejvyšší rolí, ale správu členství zvládne kdokoli z Memberů.

Důležitá souvislost pro produkční nasazení: Row-Level Security (RLS) se vynucuje jen na roli Viewer. Admin, Member i Contributor mají na modelu Write permission, takže filtr RLS obchází — vidí všechna data bez ohledu na definované role.

Pro produkční workspace je doporučenou praxí použít bezpečnostní skupinu Entra ID — správa členství pak probíhá centrálně v Entra ID, ne roztroušeně napříč jednotlivými workspace.

V praxi se obě varianty často kombinují: přímý e-mail pro výjimky nebo dočasné potřeby, bezpečnostní skupina pro standardní členství týmu. Kdo spravuje větší počet workspace, ocení, že přidání nebo odebrání člověka ze skupiny v Entra ID se projeví ve všech workspace, kde je skupina použitá — bez nutnosti procházet je ručně jeden po druhém.

Add-PowerBIWorkspaceUser -Id "<workspace-id>" `
  -PrincipalType Group -Identifier "<group-object-id>" `
  -AccessRight Contributor

Cmdlet Add-PowerBIWorkspaceUser (modul MicrosoftPowerBIMgmt, viz kapitola 7) má dvě sady parametrů. Jednotlivého uživatele přidáte přes -UserPrincipalName (e-mail). Bezpečnostní skupinu přidáte přes -PrincipalType Group -Identifier, kde -Identifier musí být object ID (GUID) skupiny z Entra ID, ne její e-mail nebo název.

Toto uspořádání se přímo propojuje s tématem Deployment Pipelines, kterému se věnuje kapitola 5, a s Power BI Apps, kterým se věnuje kapitola 3. Samotné workspace role a přímé sdílení tuto odděleně fungující architekturu nedokážou nahradit — jakmile má konzument přístup přímo do workspace, vidí i to, co ještě není hotové, a u RLS navíc riskuje, že vidí data, která vidět neměl (viz sekce 2.7).

• Role ve workspace — přehled
• Přidávání přístupu do workspace
• Premium Per User — diamantová ikona a FAQ
• RLS a workspace role