Mapa AI nástrojů kolem datové platformy

Na konzultacích teď dostávám pořád stejnou otázku. Kde končí Copilot v Power BI a kde začíná data agent? A k čemu je vlastně Copilot Studio, když máme Foundry? Odpověď se nejlíp ukazuje na mapě. Tak jsem ji nakreslil.

Nejde o deep dive. Dnešní díl je rozcestník a jednotlivým nástrojům se budu věnovat v samostatných dílech seriálu.

Proč je to tak těžké?

Důvody jsou dva. Nástrojů je hodně a mění se rychle. Za poslední zhruba dva roky se AI skill přejmenoval na data agenta, Azure AI Studio na Azure AI Foundry a pak na Microsoft Foundry. Power BI Q&A v únoru 2027 skončí. Stav jedné a té samé funkce se občas liší podle toho, kterou stránku dokumentace zrovna čtete.

A pak je tu slovo Copilot. To dnes neznamená jeden produkt, ale celou rodinu.

Tři patra

V hlavě si AI kolem dat dělím na patra:

• Ptám se – konverzační AI, která odpovídá nad daty. Copilot v Power BI, Microsoft 365 Copilot, Fabric data agent.
• Stavím agenta – platformy, kde si takového agenta postavíte sami. Copilot Studio a Microsoft Foundry.
• Vyvíjím s agentem – agentický vývoj. GitHub Copilot, Claude Code, Codex. Ty dnes umí přes MCP sáhnout i do semantic modelu.

Dnešní mapa pokrývá hlavně první dvě patra. Třetímu patru dám vlastní díl.

Základ: semantic model a Prep data for AI

Než se pustím do nástrojů – všechno z prvního patra stojí na stejném základu. Na semantic modelu. Pokud je model nepopsaný a plný technických sloupců, žádný Copilot to nezachrání.

Proto vzniklo Prep data for AI. Vyberete podmnožinu polí, kterou má AI používat (AI data schema). Doplníte instrukce s byznysovými pojmy (AI instructions). A pro nejčastější otázky připravíte schválené odpovědi (verified answers). Všechno se ukládá do modelu, ne do reportu. Takže to platí všude, kde se model s Copilotem potká – včetně data agenta.

Je to stará známá práce datového modeláře, jen s novým publikem.

Copilot v Power BI

Copilot v Power BI není jedna věc, ale několik různých funkcí:

• Copilot pane v reportu (GA) – odpovídá nad reportem, který máte otevřený.
• Standalone Copilot (preview) – celoobrazovkový, sám najde vhodný report nebo model, ke kterému máte přístup. Když odpověď v reportu není, sáhne do measures nebo si napíše DAX.
• Copilot pro tvůrce – psaní DAX, popisy measures, úpravy modelu.

Často slýchám, že Copilot „vidí celý tenant“. Nevidí. Vidí to, k čemu máte přístup vy, a admin mu to může dál zúžit na schválené modely. RLS platí.

Požadavek na kapacitu: F2 a výš nebo P1 a výš, případně Fabric Copilot capacity. Samotná Pro licence nestačí.

Microsoft 365 Copilot a Fabric IQ

Tady se na FabConu v Barceloně posunulo nejvíc. Power BI data v Microsoft Copilot Chatu jsou GA. Copilot sám pozná, který report nebo model se k otázce hodí. A k číslům přidá kontext z mailů, schůzek a dokumentů.

Zajímavost: funguje to i nad Pro a PPU workspace (Embedded kapacity ne). Potřebujete licenci Microsoft 365 Copilot (Learn ji teď vede jako Copilot Premium) a běžný přístup k reportu. Fabric kapacita podmínkou není.

Druhý krok se týká Power BI samotného. Stejný Copilot přichází přímo do Power BI a Fabricu. Zatím jako preview, jen pro držitele Copilot Premium licence a vedle stávajícího Power BI Copilotu. Na ostatní uživatele se má rozšířit později. Směr je ale vidět – čísla z Power BI a kontext z Microsoft 365 se potkávají v jednom Copilotu.

Fabric data agent

Když nechcete obecného Copilota, ale specialistu, je tu Fabric data agent. Dáte mu až pět zdrojů v libovolné kombinaci – lakehouse, warehouse, KQL databázi, semantic model, ontologii. Napíšete mu instrukce, kdy sáhnout kam, a přidáte příklady dotazů. (U semantic modelu příklady dotazů nejdou – tam agent bere to, co připravíte přes Prep data for AI.)

Agent si sám napíše SQL, DAX nebo KQL. Jen pro čtení. A má své meze: oficiálně podporuje jen angličtinu (v mém malém testu ale česky fungoval podobně jako anglicky), odpověď má strop 25 řádků × 25 sloupců a zdroje musí být ve stejném regionu.

Hlavní výhoda? Dá se volat shora. Ze standalone Power BI Copilotu, z Microsoft 365 Copilotu, z Copilot Studia i z Foundry. Postavíte ho jednou a volat ho může víc nástrojů.

Copilot Studio vs. Foundry

Pomůže analogie, kterou datoví lidé znají. Copilot Studio je pro agenty totéž, co Power Automate pro workflow. Foundry je totéž, co Logic Apps.

Copilot Studio je low-code, žije v Power Platform, spravuje se v Power Platform admin center a platí se v Copilot Credits. Staví v něm makeři, typicky agenty pro oddělení. Foundry je pro vývojáře: Azure subscription, volba modelu, vlastní kód, evaluace, platba za tokeny.

Rozšířené dělení, že Copilot Studio je „pro M365“ a Foundry „pro všechno ostatní“, ale neplatí. Copilot Studio volá přes konektory i systémy třetích stran a publikuje na web. Agenta z Foundry zase publikujete do Teams a do Microsoft 365 Copilotu. Hranice tedy není v tom, kam agent dosáhne. Je v tom, kdo ho staví, kde žije a kdo ho platí.

A pozor na detail, který vypadá nevinně. V Copilot Studiu si u data agenta volíte autentizaci. Při volbě Maker vidí všichni uživatelé data přes oprávnění autora. To si dobře rozmyslete.

Pro vývojáře: MCP a Foundry IQ

Dvě položky, které v mapě nesmí chybět. Power BI MCP servery: Authoring MCP slouží k tvorbě a úpravám modelu z agenta, Fabric IQ k odpovědím nad Power BI daty pro vlastní agenty. A Foundry IQ nad Azure AI Search, které řeší dokumenty. Zjednodušeně: Fabric IQ jsou čísla a sémantika, Foundry IQ jsou PDFka a texty.

Celá mapa v tabulce

Pro pořádek všechno na jednom místě.

Nástroj	Patro	Co dělá	Kde končí
Copilot pane v reportu	ptám se	otázky a shrnutí nad otevřeným reportem	jen jeden report; kapacita F2+ / P1+
Standalone Power BI Copilot	ptám se	najde report nebo model, ke kterému máte přístup; píše DAX	jen obsah Power BI a Fabricu, bez kontextu z M365
Copilot pro tvůrce	stavím (model)	DAX, popisy measures, úpravy modelu	jen model, ne odpovědi koncovým uživatelům
Prep data for AI	základ	AI data schema, AI instructions, verified answers, Approved for Copilot; uloženo v modelu	sám nic nezodpoví, zlepšuje všechny konzumenty modelu
Microsoft Copilot Chat s Fabric IQ	ptám se	sám vybere report nebo model, přidá kontext z M365	jen reporty a modely (ne dashboardy, ne RDL); Embedded ne; licence M365 Copilot
Copilot v Power BI a Fabricu	ptám se	totéž přímo v UI Power BI a Fabricu	zatím jen s Copilot Premium licencí, vedle standalone
Fabric data agent	ptám se / stavím	až 5 zdrojů, instrukce, dotazy SQL, DAX a KQL	oficiálně jen angličtina, 25 × 25 v odpovědi, stejný region, jen čtení
Copilot Studio	stavím	low-code agenti, konektory, publikace do Teams, M365 a na web; data agent jako tool	governance v Power Platform; platba v Copilot Credits
Microsoft Foundry Agent Service	stavím	pro-code agenti, volba modelu, tools, evaluace; publikace i do M365	vyžaduje vývoj a provoz v Azure; platba za tokeny
Foundry IQ	stavím	knowledge base nad dokumenty (Azure AI Search)	nestrukturovaná data, ne sémantika metrik
Power BI Authoring MCP	vyvíjím s agentem	agent vytváří a upravuje semantic model	ne pro odpovědi koncovým uživatelům
Fabric IQ (MCP)	stavím / vyvíjím	odpovědi nad Power BI daty pro vlastní agenty	jen konzumace, ne tvorba modelu
GitHub Copilot, Claude Code, Codex	vyvíjím s agentem	agentický vývoj kódu, TMDL a notebooků přes MCP	nejsou to konverzační nástroje pro byznys uživatele

Závěr

Dnešní článek měl být mapou, ne průvodcem. Základ tvoří semantic model připravený pro AI. Nad ním se ptají Copilot v Power BI, Microsoft 365 Copilot a data agent. A agenty si stavíte buď v Copilot Studiu, nebo ve Foundry – podle toho, kdo staví a kde to má žít.

Každému z nástrojů dám samostatný díl. Začnu přípravou dat pro AI, protože bez ní je všechno ostatní loterie.

Co je dbt a proč by mělo zajímat Power BI vývojáře

Sémantický model v Power BI umí popisy (descriptions) u tabulek, sloupců i measures. Datový sklad pod ním obvykle ne. Nebo aspoň ne tak, aby je někdo skutečně udržoval. Jestli jste někdy otevřeli tabulku s názvem col_17_flg a hledali, co znamená, víte, o čem je řeč.

Tenhle článek je pro vývojáře z Power BI světa, kteří uvažují o Fabricu a slyšeli o dbt. Nebude to kompletní průvodce dbt. Vysvětlím, co to je, proč mě to zaujalo a jak se z popisů napsaných jednou dostanete až do sémantického modelu.

Co je dbt (a co není)

dbt (data build tool) je nástroj na transformace dat uvnitř databáze. Nenačítá data, neorchestruje celý svět a nemá vlastní úložiště. Dělá jednu věc: ze SQL dotazů (modelů) postaví tabulky a views ve správném pořadí a ohlídá, že výsledek sedí.

Pro člověka z Power BI se to dá přirovnat takto:

• model je jeden SELECT uložený v souboru. dbt z něj udělá view nebo tabulku. Něco jako dotaz v Power Query, jen v SQL a ve skladu.
• ref() je odkaz na jiný model. Podle něj dbt pozná závislosti a sestaví lineage (graf, co z čeho vzniká). V Power BI znáte podobné zobrazení závislostí.
• test je pravidlo nad daty (unique, not_null, vztah mezi tabulkami). Spustí se spolu s buildem.
• YAML soubor vedle modelu popisuje model a sloupce: tady se píší descriptions. A právě to je důvod, proč jsem u dbt skončil.

Všechno jsou to textové soubory v Gitu. Pro vývojáře z Power BI, který si zvykl na PBIP a TMDL, to není nic cizího.

dbt ve Fabricu

Fabric má vlastní položku dbt job (Data Factory). Spouští dbt Core ve spravovaném runtime, takže nic neinstalujete lokálně. Projekt vezmete z ukázky (Jaffle Shop) nebo z GitHub repozitáře, vyberete cíl (Warehouse, Lakehouse a další podporované adaptéry) a job můžete naplánovat. Po běhu uvidíte lineage, zkompilované SQL a výsledky. Podle oznámení z FabCon Europe (29. 9. 2026) je dbt job ve stavu GA. Oznámení: FabCon/SQLCon Barcelona 2026: What’s new in Fabric Data Factory. Zapíná se v tenant settings.

Založení dbt jobu: vzorový projekt Jaffle Shop

Připojení projektu k cíli: výběr profilu adaptéru

Adaptéry jsou dva důležité:

• dbt-fabric pro Fabric Data Warehouse (T-SQL),
• dbt-fabricspark pro Lakehouse (Spark SQL přes Livy API, zapisuje Delta tabulky do OneLake).

Rozdíl je podstatný: SQL analytics endpoint u Lakehouse je pro dbt jen pro čtení, takže transformace ve stylu T-SQL patří do Warehouse. Pokud je váš tým spíš Spark, sáhnete po Lakehouse.

Nový Warehouse jako cíl dbt jobu

Profil adaptéru: Warehouse, schéma jaffle_shop, nahrání seed dat

Dva praktické limity z dokumentace: dbt job nemá build cache (každý běh kompiluje projekt od nuly) a ne všechny partnerské adaptéry jsou ve Fabricu podporované.

Proč mě to zajímalo: kde žijí popisy

V sémantickém modelu Power BI je popis jednoduchý. Zapíšete ho do vlastností sloupce nebo do TMDL a uvidí ho každý, kdo model použije, včetně Copilota a dalších nástrojů, které se na model dotazují.

Pod tím je ale datový sklad. A tam popisy sloupců uložit nejde. Standardní cesta ze SQL Serveru (extended properties) ve Fabric Warehouse nefunguje: sp_addextendedproperty Warehouse odmítne s hláškou, že procedura není podporovaná. Praktický důsledek: popisy se nejčastěji řeší vedle databáze. Excelem, wiki nebo vlastní konfigurační databází, kam se píše, co který sloupec znamená. Funguje to, dokud to někdo udržuje. Obvykle to trvá do prvního release.

dbt tenhle problém řeší jinak. Popis sloupce leží ve stejném YAML souboru jako model, ve stejném commitu a prochází stejným code review. Změníte sloupec a popis vidíte hned vedle.

Ukázka z demo projektu Jaffle Shop (fiktivní e-shop, který dbt i Fabric nabízejí jako vzorový projekt):

version: 2

models:
  - name: customers
    description: This table has basic information about a customer, as well as some derived facts based on a customer's orders
    columns:
      - name: customer_id
        description: This is a unique identifier for a customer
        tests:
          - unique
          - not_null
      - name: first_order
        description: Date (UTC) of a customer's first order
      - name: number_of_orders
        description: Count of the number of orders a customer has placed
      - name: total_order_amount
        description: Total value (AUD) of a customer's orders

schema.yml s popisy v editoru dbt jobu ve Fabricu

Delší popis nemusíte cpát do YAML. Dá se napsat jako doc blok v Markdownu (docs.md) a z YAML na něj odkázat přes {{ doc("orders_status") }}. V demu takhle vypadá popis stavů objednávky:

Doc blok orders_status v souboru docs.md

Popisy a závislosti skončí v artefaktu manifest.json, který dbt job ve Fabricu ukládá při každém běhu do složky target v OneLake. Příkaz dbt docs generate k tomu přidá catalog.json se skutečnými sloupci a typy z databáze. Pozor: ve Fabricu se vygenerovaná dokumentace zatím nerenderuje jako web, máte jen soubory.

Příkazy dbt jobu, mezi nimi i docs generate

Popisy až do databáze

dbt umí popisy zapsat i do samotné databáze, jako komentáře k tabulkám a sloupcům. Slouží k tomu konfigurace persist_docs:

models:
  my_project:
    +persist_docs:
      relation: true
      columns: true

Na řadě platforem to funguje (Snowflake, Databricks, BigQuery a další). Pro Fabric je situace rozdělená a vyzkoušel jsem si obě varianty:

• Warehouse (dbt-fabric): dokumentace dbt persist_docs pro tento adaptér neuvádí a test to potvrdil. dbt run s persist_docs končí chybou „alter_relation_comment macro not implemented for adapter fabric“, u sloupců totéž s alter_column_comment. Model s persist_docs tedy spadne, pro Warehouse ho nechte vypnutý.
• Lakehouse (dbt-fabricspark): persist_docs funguje. Popis tabulky i sloupců skončí v metadatech Delta tabulky (ověřil jsem v Delta logu). SQL analytics endpoint je ale do T-SQL metadat nepromítne (sys.extended_properties zůstane prázdné), takže přes T-SQL je neuvidíte.

Proč to ale není slepá ulička: popisy nemusí být v databázi, aby je někdo přečetl. Jsou v dbt projektu a v artefaktech. Kdo potřebuje metadata, přečte je odtud. A tím se dostávám k tomu, co mě na tom baví nejvíc.

Agent staví sémantický model a popisy si přečte sám

Sémantický model Power BI dnes umíme stavět i s agentem. Microsoft k tomu má Power BI Authoring MCP server (lokální verze se instaluje jako powerbi-modeling-mcp), který umí s modelem pracovat (tabulky, sloupce, measures, vztahy, popisy). Agent pak může model sestavit nad vaším skladem.

Obvyklý problém: agent vidí názvy sloupců a typy, ale neví, co znamenají. Model pak vznikne bez popisů, nebo se popisy domýšlejí. A domýšlené popisy jsou horší než žádné.

Pokud ale agent dostane k dispozici dbt projekt (nebo manifest.json), může popisy převzít. Zadání je jednoduché: „Postav sémantický model nad schématem jaffle_shop, popisy a vztahy převezmi z dbt projektu.“ Agent přečte popis customer_id z YAML a zapíše ho jako description sloupce v modelu. Vztah orders → customers odvodí z testu relationships, který je v YAML u sloupce orders.customer_id. Co jednou popíšete v dbt projektu, agent přenese do sémantického modelu bez ručního přepisování. Copilot a Fabric data agent pak nad modelem mají k dispozici popisy, které byste jinak psali ručně.

Zadání agentovi a shrnutí jeho běhu (výstup přepsaný do přehledné podoby), včetně nahlášeného nesouladu

Výsledný model v TMDL view: popisy z dbt jako /// komentáře

Jedna pojistka: popis z dbt je vstup, ne pravda. Hezky se to ukázalo hned v demu. YAML popisuje u zákazníka sloupec total_order_amount (viz ukázka výše), jenže tabulka ve Warehouse ho nemá, místo něj obsahuje customer_lifetime_value bez popisu. Nesoulad je přímo ve vzorovém projektu. Agent to porovnal se skutečnou tabulkou, nesouhlasící popis nepoužil a nesoulad nahlásil. Kdyby popisy jen slepě kopíroval, měli byste v modelu popis ke sloupci, který neexistuje. Agentovi proto dejte za úkol model postavit a nesoulady hlásit, ale zkontrolovat ho musíte vy.

Demo

Demo stojí na vzorovém projektu Jaffle Shop (fiktivní e-shop: zákazníci, objednávky, platby) ve Fabric Warehouse. Postup:

1. dbt job ve Fabricu nad Warehouse, modely ve dvou vrstvách (staging a výsledné tabulky customers a orders).
2. Popisy sloupců výsledných tabulek v YAML, testy unique, not_null, relationships a accepted_values.
3. Spuštění jobu s příkazem build, kontrola lineage a výsledků testů.
4. Agent načte popisy z dbt projektu a postaví nad Warehouse sémantický model (Direct Lake).
5. Výsledek v Power BI: popisy tabulek a sloupců ve vlastnostech modelu.

Lineage view v dbt jobu: seedy, staging a výsledné tabulky

Výsledek dbt build: modely i testy prošly

Sémantický model (Direct Lake) ve Fabricu: popis sloupce first_order převzatý z dbt

Chování persist_docs ve Warehouse a v Lakehouse jsem zkoušel zvlášť na malém testovacím modelu (výsledky viz výše).

Kdy to dává smysl a kdy ne

Dává to smysl, pokud:

• máte transformace ve skladu v SQL a chcete je verzovat, testovat a mít lineage,
• chcete jedno místo pro popisy, které se dostane i do sémantického modelu,
• už dbt znáte, nebo máte tým, který zvládne Git.

Nedává to smysl, pokud:

• máte pár tabulek a transformace řešíte jednou za čas,
• nikdo nechce psát popisy: dbt je nevymyslí, jen je udrží u kódu,
• potřebujete něco, co dbt Core nemá. dbt job ve Fabricu dnes spouští dbt Core, novější engine Fusion v něm zatím není.

Závěr

Dnešní článek měl ukázat, co je dbt a proč ho zvážit ve Fabricu, i když jste vývojář Power BI. Pro mě je hlavní důvod popisy: napsat je jednou u kódu a nechat je přečíst agenta, který staví sémantický model. Warehouse a Lakehouse se v tom chovají odlišně, proto si to vyzkoušejte na malém projektu dřív, než to nasadíte na něco důležitého.

Zdroje:

• dbt job ve Fabricu (Microsoft Learn)
• Dokumentace a doc bloky v dbt
• persist_docs (dokumentace dbt)
• dbt-fabricspark setup (dokumentace dbt)
• Power BI MCP servery (Microsoft Learn)

FabCon Europe 2026 Barcelona – přehled pro Power BI a Fabric

Loni jsem z vídeňského FabConu psal, že pokud to jen trochu půjde, pojedu na další ročník znovu. Letos mi to fyzicky nevyšlo. Sedím doma a FabCon sleduju na dálku – keynote posty, produktové blogy, feature summary. Bedlivě.

Tenhle článek je přehled toho podstatného, co Microsoft k letošnímu FabConu a SQLConu oznámil. Nejedná se o kompletní seznam – jen zářijový Fabric Feature Summary má víc položek, než kolik kdo z nás stihne za týden vyzkoušet.

Power BI jako kód: PBIP je GA

Pro mě zpráva dne. Power BI Projects (PBIP) jsou Generally Available. A PBIR je nově výchozím formátem reportu pro PBIX i PBIP – legacy reporty se při editaci automaticky převádějí. Pokud máte skripty, které parsují starý report.json, zkontrolujte je. Btw. tady se jedná o dobrou zprávu pro všechny, kteří jsou na on premises Power BI Report serveru. Protože tam se dostanou jen věci v GA... Další release?

K tomu Power BI Agentic Experiences jsou GA – Power BI Authoring MCP, Power BI Desktop Bridge CLI a skills-for-fabric. Remote Power BI Authoring MCP Server je v preview. Nic neinstalujete a funguje i na Macu. Lokální MCP zůstává GA.

Na Power BI Day 2026 jsem živě ukazoval Claude nad Power BI reportem. Tohle je pro mě jasný signál, že verzování a práce s agenty nejsou experiment, ale standardní cesta. O integraci s Gitem jsem psal tady.

Aplikace v Power BI – i pro Pro a PPU

Agentic app creation v Power BI Desktop – nad semantic modelem popíšete v přirozeném jazyce, co potřebujete, a vznikne aplikace. Umí i write-back a publikuje se do Fabricu přes Fabric Apps. Je to preview, termín ale Microsoft uvádí různě (jednou týdny, jednou měsíce). Nechám se překvapit.

Zásadní je licencování. Apps in Power BI budou v preview i pro Power BI Pro a PPU bez příplatku, včetně Fabric Apps a Fabric Database – až 1 GB na aplikaci. Fabric Apps se mají objevit i v Org apps (Coming Soon).

Fabric Apps se připojují na semantic model read-only a posílají do něj DAX dotazy, do SQL DB a warehouse jde i zapisovat. Delegovaná autentizace vynucuje oprávnění včetně RLS. Aplikace tak dostane stejné číslo jako report a stejný uživatel uvidí stejná data. Jak jsem data app nad DAX dotazy stavěl v červnu, popisuju v článku Fabric Apps – náhrada Power BI reportů?

Modelování a DAX

• Vytváření a editace DirectQuery modelů v Power BI service – další krok k paritě webu a Desktopu.
• APPROXIMATEDISTINCTCOUNT pro Import a Direct Lake (preview). Standardní chyba kolem 1,6 %. Na počty zákazníků v přehledovém reportu ano, na finanční čísla ani náhodou.
• String Indexing a Full-Text Search v semantic modelech (preview).
• Nový Power Query editor v Power BI Desktopu (preview).
• Semantic views – governed metriky a sémantika definované přímo nad daty ve OneLake. Zatím jen „early look".
• Apache Ossie (incubating) – vendor-neutral standard výměny sémantických metadat, za kterým stojí Microsoft spolu se Snowflake. Open source Microsoft converter převede Ossie dokument na Power BI semantic model i Snowflake Semantic View – sémantiku definujete jednou, bez přesunu dat. Výhledově má být DAX uznávaným dotazovacím jazykem Ossie.

Copilot a governance

Fabric IQ v Microsoft Copilot Chat a Cowork je GA. Copilot odpovídá nad vašimi Power BI modely a reporty, a to bez dodatečných nákladů na AI tokeny. Fabric IQ MCP Server je taky GA.

Microsoft 365 Copilot přímo v Power BI a Fabricu je v preview, se sdílenou historií konverzací. Fabric data agents v Microsoft Copilot Studio jsou GA.

A teď to, co bych jako admin řešil nejdřív. Na semantic modelu přibylo nastavení, které zakáže read-only uživatelům přístup k modelu přes Copilot a Microsoft MCP nástroje. Výchozí hodnota je povoleno. K tomu Restrict from Copilot – admin určí, které semantic modely smí do AI experience. Sensitivity labels a DLP se do Copilot experience propisují. Pokud máte modely, které do AI nepatří, projděte je teď, ne až po incidentu.

Drobnosti, které potěší

• Export do Excelu („Data with current layout") ze 150 000 na 500 000 řádků (GA).
• Visual calculations pro small multiples (GA). O visual calculations jsem psal zde.
• Design ribbon (GA).
• Pozor na deprecation: od října ztratí verze Power BI Desktopu z března 2026 a starší možnost ukládat do OneDrive/SharePoint. Aktualizujte.

Fabric: kapacity a billing

Fabric zero-provisioned (F0) – start bez provisionované kapacity, s on-demand billingem jako výchozím (preview). On-demand billing napříč Fabric workloady má brzy přijít v preview a on-demand billing pro OneLake compute – přístup k datům nezávislý na běžící kapacitě – má dorazit v preview v příštích týdnech. F0 chci otestovat hned, jak bude k dispozici.

Dál: Capacity overage je GA, SKU F4096 a F8192 jsou GA a workspace-level surge protection má být GA brzy.

CI/CD, Git a observability

• Deployment plans (preview) – nový workspace item, vizuální pořadí nasazení, YAML jako source of truth, kroky před a po nasazení.
• Bulk import/export item definition APIs (GA).
• Git: branch workspace, selective branching, compare and commit (GA); file-level commit a branch workspace admin profile (preview).
• Observability in Fabric (preview) – workspace monitoring sjednocený do jednoho eventhouse, přepracovaný Monitor Hub, pohled na kapacitu a Activator alerty na joby. Fabric Observability Insights (public preview) – operations agent vyšetří třeba selhání pipeline.
• Fabric Core MCP Server (GA).

Governance a OneLake

• Policies in Fabric (preview) – řízení přístupu na základě atributů.
• DLP policies – restrict access to sensitive data (GA), rozšířené OneLake catalog Govern (GA), Outbound access protection pro OneLake shortcuts (GA).
• OneLake catalog v Excelu (preview) a na úrovni tabulek a sloupců včetně náhledu dat.
• OneLake Table Read API (preview) – čtení Delta/Iceberg tabulek bez SQL přes Apache Arrow, s vynucením table/row/column security.
• Azure Databricks: čtení a zápis přes native storage v OneLake – nově podporované v produkci.
• IQ sharing (preview, brzy) – sdílení governed dat a kontextu mimo organizaci.
• Mirroring Google BigQuery (GA), obousměrná integrace se Salesforce Data Cloud 360 (preview), shortcuts na verzovaná data v lakeFS, federace Iceberg katalogů (AWS Glue, Google).

Data Factory

• Mirroring for SharePoint Lists (GA) a rozšířený mirroring včetně Change Data Feeds (GA).
• Snowflake Security Roles Replication (public preview) – role a oprávnění ze Snowflake se překládají do OneLake security.
• Mirroring Dynamics 365 Business Central – brzy.
• dbt Job in Fabric (GA), dbt Core v2 (Fusion) brzy.
• Dataflow Gen2: optimalizovaný zápis do lakehouse, V-Order compression controls, Shared Queries, nové destinace včetně Excelu a e-mailu, stažitelná diagnostika.
• Pipelines: Lakehouse Maintenance activity (vacuum/optimize), pipeline-level dependencies, exponential retry a Approval activity.
• Upgrade experience z Azure Data Factory – ADF pipelines vidíte ve Fabric workspace, s posouzením kompatibility a postupným upgradem.

Data Engineering a Data Warehouse

• Data engineering agent (preview) – technologie z akvizice Osmos, pro migrace, modernizaci lakehouse a ETL. Funguje i z GitHub Copilotu, VS Code, Codexu nebo Claude Code.
• Runtime 2.0: Spark 4.0 + Delta Lake 4.0.
• Materialized Lake Views (GA) a Custom Live Pools (GA).
• GPU-accelerated query execution ve warehouse (public preview) – zapíná se na úrovni workspace, bez změn dat a SQL.
• Custom SQL pools (GA), Teradata Migration Assistant (preview), nový node-based billing model pro warehouse.
• Migration assistant ze Synapse dedicated SQL pools umí nově incremental migration.

Fabric Apps a Planning

Fabric Apps dostaly PostgreSQL vedle SQL Serveru, TypeScript functions se Secret Store, vestavěné metriky používání a plugin Rayfin pro GitHub Copilot. Rayfin SDK a CLI jsou open source. Deployment pipelines pro Fabric Apps jsou zatím v plánu na zbytek roku.

U Planningu (GA od července) přibyl Native Planning Engine (preview, Rust + Apache Arrow, až 10× výkon), writeback plánu zpět do semantic modelu a event triggery po writebacku – spustíte pipeline, refresh modelu nebo notebook. O cestě od SSAS writebacku k Fabric Planningu jsem psal v tomto článku.

Fabric IQ a Real-Time Intelligence

• Agentic tvorba ontologií ze semantic modelů, OneLake dat a dokumentů – včetně Power BI DAX measures v ontologii.
• Operations agent: root-cause analysis a pre-approved actions (preview).
• Business Events (GA), Copilot tvorba Real-Time Dashboardu (preview).

SQLCon

• Database Hub in Fabric (preview).
• Database agents pro SQL a PostgreSQL – rolling out v preview.
• DiskANN vector indexes (GA) v Azure SQL DB Hyperscale, SQL MI a SQL database ve Fabricu.

Závěr

Dnešní článek měl shrnout, co Microsoft oznámil na FabConu Europe 2026 v Barceloně – nejdřív pro Power BI, potom pro Fabric. Pro Power BI vývojáře je to hlavně PBIP v GA a agentic vývoj, který opustil preview. Pro Fabric nový pohled na billing a spousta práce kolem governance a CI/CD.

Berte to jako snapshot stavu k 30. 9. 2026 – u řady položek Microsoft termín ani status zatím neuvádí. Svůj osobní výběr toho, co budu zkoušet jako první, pošlu v příštím Weekly BI Digestu.

Fabric Apps – náhrada Power BI reportů?

Minulý týden jsem vzal svůj starý report a zkusil z něj udělat Fabric Data App. Ten report je jedno z mých prvních produkčních Power BI děťátek. Je to můj otloukánek pro všechny možné demonstrace – znám ho datově i byznysově, vím co jsem v něm dělal historicky špatně a co bych dneska udělal jinak. Právě proto je to vždycky kandidát na hraní. O pár dní později jsme to s Vojtou rozebrali v Cestě do Fabricu, protože na Buildu 2026 to bylo jedno z nejzajímavějších oznámení.

Co jsou Fabric Apps

Fabric Apps jsou nový typ itemu ve workspace. V kostce – webová aplikace, která běží přímo na Fabricu. Žádný externí hosting, žádné lepení krabiček od různých vendorů. Autentizace přes Entra ID, governance přes workspace permissions, data přes OneLake.

Dají se rozdělit na dvě části. Jednak operační appky – plnohodnotné webové aplikace, kde data nejen čtete, ale i zapisujete. Pamatujete, jak jsme se v jednom z předchozích dílů Cesty do Fabricu bavili o tom, že write-back může řešit i planning? Tohle je přesně ta kategorie. A zajímavé je to i pro nás z Power BI světa, protože to řeší věci, které Power BI samo o sobě nikdy neřešilo. A pak data apps – vizualizační dashboardy nad sémantickým modelem, kde se dotazy posílají přes DAX. Na ty se zaměřím hlavně.

Kde je Rayfin

S Fabric Apps úzce souvisí Rayfin – open-source SDK a CLI. Rayfin je nástroj, Fabric Apps je výsledek. Napíšete npx rayfin up a Rayfin vám nasadí kompletní backend – SQL databázi, GraphQL API, autentizaci, static hosting – přímo do vašeho Fabric tenantu. Microsoft to na Buildu demonstroval ve spolupráci s Replitem a byznys problém pojmenoval přesně: vygenerovat frontend zvládne dnes agent za hodinu. Produkční backend, který je bezpečný, škálovatelný a s důrazem na governance – to je ta těžší část. Rayfin ji řeší tím, že to všechno dědí z Fabricu. Detaily najdete v oficiálním blog postu na Fabric Community.

Co jsem zkoušel

Jak to vypadá pod kapotou? Úplně jinak než v Power BI. Tady není žádné uživatelské rozhraní. Všechno se píše jako kód – nebo se musíte spolehnout na coding agenta (GitHub Copilot, Claude Code nebo jiný). Pod každou vizualizací je soubor s koncovkou .dax, který posílá DAX dotaz do sémantického modelu. Samotné vizualizace kombinují TypeScript, CSS, Vega/VegaLite. Máte nad tím absolutní kontrolu – můžete ten DAX dotaz odladit, můžete každý pixel posunout. Ale musíte to umět, nebo donutit agenta, aby to uměl za vás.

Nechal jsem Claude Code, ať se podívá do prohlížeče na můj starý report, prokliká si ho a vygeneruje mi novou verzi jako data app. Zadání: podívej se, co tam je, zachovej ty informace, ale zkus to udělat líp – drž se best practices pro vizualizace. Tady se mi agent rozjel.

Před (originál Power BI)

Po (Fabric Data App)

Dvě stránky, které měly být identické (lišila se jen metrika – obrat vs. marže), mi vygeneroval každou jinak. Některé vizualizace chyběly, některé byly úplně jiné. Interakce mezi vizualizacemi – to, co má Power BI by design – tady musíte explicitně naprogramovat. Kliknu do sliceru a chci, aby se překreslily všechny grafy na stránce? Musím to říct. Export do Excelu? Řazení? Prokliky? Totéž.

Jeden praktický postřeh. Při nasazení mi Rayfin automaticky vygeneroval Fabric SQL database, kterou jsem pro čistou data app vůbec nepotřeboval – tahal jsem data ze stávajícího sémantického modelu, ale zapomněl jsem to agentovi říct. Krátkodobě to vytížilo mou F2 kapacitu na 886 %. Jakmile jsem databázi odstranil, samotné interakce s data app byly z pohledu CU v podstatě zadarmo.

Nahradí to Power BI?

Ne. A myslím si, že to ani nemá. Kurt Buhler z Tabular Editoru to rozebral v článku, kde to přirovnal k legu a 3D tiskárně. Power BI je lego – pokládáte kostičky, máte hotový výsledek rychle, self-service uživatel si postaví report sám. Fabric Data Apps jsou 3D tiskárna – máte absolutní volnost, ale potřebujete úplně jiný skill.

Připomíná mi to příchod Power BI vedle Reporting Services. Tehdy všichni spekulovali, jestli Power BI nahradí paginated reporty. Microsoft v té době možná hůř komunikoval vizi a teprve čas ukázal, že to není náhrada, ale doplněk – vykrytí slabých míst platformy. Tady čekám totéž. Power BI zůstane pro self-service analytiku, pro běžného business uživatele, který si otevře Power BI Desktop a při troše štěstí report nakliká. Fabric Apps jsou pro profi vývojáře, který potřebuje custom, pixel-perfect, propojitelné s aplikační vrstvou – zápisy do databáze, napojení na externí API, komentování.

Kde to ale vidím jako skutečný přínos, je potenciální náhrada Power Apps. Vojta zná firmy, kde Power Apps používají třeba jako katalog reportů – přesně tohle by šlo nativně přesunout do Fabric Apps. Pokud už máte Fabric jako platformu, proč byste do toho vnášeli další platformu s vlastním licenčním chaosem?

Na co si dát pozor

Fabric Apps jsou v preview a nejsou dostupné ve všech regionech. Já jsem narazil s kapacitou v North Europe – musel jsem si vytvořit novou kapacitu ve West Europe. S Vojtou jsme v podcastu řešili, jestli se k Fabric Apps dostane uživatel bez Power BI Pro licence. V tu chvíli jsme to nevěděli, tak jsem to pak dohledal – uživatel s oprávněním "Run and interact" může Fabric App používat bez Pro licence, ale pouze na kapacitě F64 a výš. Pod F64 je Pro stále potřeba. Pokud jste na menších kapacitách – já na svém testovacím tenantu jedu na F2 – tak to je dobré vědět. A jedno obecnější riziko, o kterém se na LinkedIn už diskutuje – díky agentům je dnes schopný vygenerovat webovou aplikaci skoro kdokoliv. Nechat si to kompletně nagenerovat a nerozumět tomu kódu vůbec – to není úplně bez rizika. Ale to není specifické pro Fabric Apps, to je problém celého vibe codingu. Je to čerstvě vytažené z trouby.

Závěr

Dnešní post se věnoval Fabric Apps – novému typu workspace itemu, který rozšiřuje Fabric o plnohodnotné webové aplikace. Fabric už není jen základna pro vaše data, ale je to kompletní platforma. Pro vizualizační scénáře jsou data apps alternativa s daleko větší volností než Power BI, ale za cenu výrazně vyšší komplexity. Pro operační scénáře je to potenciálně cesta, jak se zbavit Power Apps v kontextu Fabricu. Stále je to preview, stále je to v plenkách. Já osobně budu číhat na use case, který bude lepší fit pro Fabric Data App než pro Power BI report. Do té doby jedu dál Power BI. A budu se seznamovat i s operational apps – to je pro mě zatím neprobádané území.

V Cestě do Fabricu jsme s Vojtou rozebrali i další střípky z Buildu 2026 – storage tiers, GPU-akcelerovaný warehouse a další.

Microsoft Build 2026 – přehled pro Fabric a Power BI

Včera v 18:00 CEST spustil Satya Nadella keynote Microsoft Build 2026 ze San Francisca. Sledoval jsem to živě, s otevřeným Build Live blogem a refreshovaným Fabric Blogem. Letos Microsoft nahradil tradiční Book of News real-time blogem.

Nebudu procházet všech 100+ announcementů. Zaměřím se na to, co je relevantní pro nás – lidi, co pracují s Power BI a Microsoft Fabric. Pokud vás zajímá AI infrastruktura, Surface hardware nebo quantum computing, tohle není ten správný článek.

Microsoft IQ – sémantický mozek pro agenty

Hlavní story letošního Build se dá shrnout do jednoho slova: agenti. Microsoft představil Microsoft IQ jako sjednocenou inteligentní vrstvu – kombinaci Work IQ (data z M365), Foundry IQ (znalostní báze), Fabric IQ Ontology (business sémantika) a nového Web IQ (grounding z webu). Je to GA od včerejška.

A tady je klíčová věta pro Power BI svět: sémantické modely Power BI jsou explicitně základem, na kterém agenti staví. Microsoft mluví o 30+ milionech sémantických modelů v produkci. Ontologie v Fabric IQ tyto modely rozšiřují o operační kontext – entity, vztahy, pravidla, akce. GA by mělo být v nejbližších měsících.

Jinými slovy – dobře navržený sémantický model není jen základ pro reporty, ale i pro agentní AI. Pokud jste investovali čas do kvalitního modelování, právě se vám to začíná vracet.

GPU-akcelerovaný Fabric Data Warehouse

Tohle je technicky asi nejzajímavější Fabric novinka na Build. Fabric Data Warehouse dostane GPU akceleraci – v interních benchmarcích Microsoft naměřil až 7× rychlejší výkon oproti třem hlavním cloudovým warehoussům. Výzkum za tím dostal cenu ACM SIGMOD za Best Industry Paper 2026. Early access preview bude v červenci 2026.

Data Agents v M365 Copilot – GA

Fabric Data Agents jsou nově GA v Microsoft 365 Copilot. K tomu přibyla podpora Service Principals, sledování přes Microsoft Foundry a Creator Agent pro SQL a Eventhouse zdroje. To všechno je v červnovém Fabric Feature Summary, který vyšel – jak jinak – souběžně s keynotem.

Copilot Credits a nový consumption model

Agent work přechází na consumption model: pay-as-you-go za $0.01/credit, nebo předplacené balíčky. Per-user Copilot licence zůstává pro lidské používání Copilota. Jinými slovy – agenti si platí zvlášť. Tohle bude zajímavé sledovat z pohledu FinOps.

OneLake – storage tiers a item-level reporting

Dvě praktické novinky v preview. Za prvé – lifecycle management pro automatický přesun dat mezi storage tiers (podle created/modified/accessed). Za druhé – item-size reporting, které konečně ukazuje storage breakdown na úrovni jednotlivých itemů, včetně system a soft-deleted dat. To je přesně ta viditelnost, co v Capacity Metrics app chybí.

Rayfin – backend jako služba přímo ve Fabric

Tohle je pro mě osobně jedna z nejzajímavějších novinek. Rayfin je open-source SDK a CLI, které umožní definovat kompletní aplikační backend v kódu – datový model, business logiku, API, autentizaci, přístupová pravidla – a jedním příkazem to celé nasadit do Microsoft Fabric. Data zůstávají v OneLake, aplikace běží jako first-class Fabric artefakt a automaticky dědí governance a zabezpečení tenantu.

Prakticky řečeno – je to odpověď na problém, který zná každý, kdo viběkóduje: AI vám vygeneruje frontend za hodinu, ale backend pro produkci je na týdny. Rayfin tu mezeru chce zavřít. Launch partnerem je Replit – postavíte aplikaci v Replitu, napíšete "rayfin up" a backend se nasadí do vašeho Fabric tenantu. Pricing zatím nebyl zveřejněn a bez Fabric kapacity to nepoběží – není to standalone služba. Preview je dostupné od včerejška.

Fabric Apps – custom webové dashboardy nad sémantickým modelem

Nový typ Fabric itemu, který by mohl být pro Power BI komunitu tou nejzásadnější novinkou z celého Build. Fabric Apps umožňují vytvořit kompletní webovou aplikaci – včetně dashboardů s vizualizačními knihovnami jako Vega nebo D3.js – a dotazovat se sémantického modelu v DAXu. Autentizace, RLS, governance – to všechno se dědí z Fabric platformy.

Důležitý detail: žádné UI na tvorbu. Je to čistě code-first workflow – HTML, CSS, TypeScript, DAX. Očekávaný způsob tvorby je přes coding agenty jako GitHub Copilot nebo Claude Code. Nenahrazuje to Power BI reporty – pokud potřebujete standardní self-service reporting, Power BI nikam neodchází. Ale pokud chcete pixel-perfect dashboard s plnou kontrolou nad vizualizacemi, tohle je nová cesta.

Kurt Buhler to na LinkedInu shrnul výstižně – přirovnal to k rozdílu mezi stavebnicí Lego a 3D tiskárnou. Větší volnost, větší komplexita, jiné use cases. Ve svém testování uvádí, že tvorba bespoke dashboardu byla s Fabric Apps výrazně rychlejší než v Power BI. Pokud vás téma zajímá, doporučuji jeho podrobný článek na Tabular Editor blogu.

A co ještě stojí za zmínku

V kostce: CI/CD pro SQL analytics endpoint (preview). GitHub Enterprise Cloud s data residency pro Git Integration (GA). Materialized Lake Views fungují across lakehouses a workspaces. Real-Time Intelligence dostalo AI-powered vizuály a Kafka + Service Bus konektory jsou GA.

Z platformových věcí mimo Fabric: Microsoft Foundry má 11 000+ modelů v katalogu, včetně Claude a GPT-5.5. Nová kategorie "Autopilots" s Microsoft Scout. A pro developery – GitHub Copilot CLI umí nově pracovat s Fabric IQ skills přímo z terminálu.

Co nebylo řečeno

Build je tradičně o architektonické strategii a developer preview. Nepadlo nic o licencování Fabric SKU ani o cenových změnách – to bývá doména Ignite. Konkrétní GA milníky pro Fabric IQ Ontologies a Power BI novinky očekávám na FabCon Europe v Barceloně (28. 9.–1. 10. 2026). Tam se uvidíme.

Závěr

Letošní Build jasně ukazuje směr: sémantický model už není jen základ pro reporty, ale pro celou agentní vrstvu. GPU akcelerace Warehouse je technicky impozantní a OneLake storage management jsou přesně ty practical improvements, co v produkci chybí. Podrobněji tohle probereme s Vojtou v příštím díle podcastu Cesta do Fabricu.

Zdroje

• Microsoft Build 2026 Live Blog (náhrada za tradiční Book of News)
• Building Agentic Apps with Microsoft Fabric and Microsoft Databases (Arun Ulag, Azure Blog)
• Fabric June 2026 Feature Summary (Patrick LeBlanc)
• Introducing Rayfin (Fabric Blog)
• Fabric Apps explained: Visualization as code in a data app dashboard (Kurt Buhler, Tabular Editor Blog)

Úpravy dat v BI modelech: od SSAS přes Power Apps až po Fabric Planning

Kdykoliv na školení Power BI přijde někdo z controllingu, tak se ta otázka objeví zhruba do první hodiny: „A jak se v tom dají upravovat čísla?" BI bylo odjakživa primárně o zobrazování. Nikoliv o editaci. Vojta Šíma, se kterým natáčím podcast Cesta do Fabricu, to říká na svých školeních na rovinu: přišli jste z Excelu, tak pojem buňka tady neexistuje — na to zapomeňte.

V posledním díle podcastu jsme s Vojtou prošli celou historii tady té funkcionality — od prehistorie přes mezistupně až po Fabric Planning. Tenhle post to shrnuje i s technickými detaily, které se do podcastu nevešly.

Historické okénko: writeback v době SSAS Multidimensional

Potřeba zapisovat data zpět do modelu není nová. V době SSAS Multidimensional — na jehož engine je Power BI postaveno — to existovalo pod názvem writeback. Pod measure group vznikly minimálně 2 partitions: jedna zobrazovala aktuální data z databáze, druhá držela změny a zapisovala je do databázové tabulky. Uživatel mohl zapisovat buď přes MDX příkazy (k tomu existovaly nástroje třetích stran), nebo od Excelu 2010 přímo z kontingenční tabulky připojené na multidimenzionální model.

Záludnost spočívala v alokaci. Pokud člověk plánoval na vyšší úrovni hierarchie — třeba na úrovni roku a produktové kategorie — musela se ta čísla zhmotnit na detailní úrovni. Rovnoměrná alokace mohla v horším případě vygenerovat statisíce až miliony řádků. Podle toho, kolik bylo možných kombinací. Kdo tohle zažil v produkci, ví, o čem mluvím.

V době Power BI a SSAS Tabular (2. generace) Microsoft na writeback dlouho nativní odpověď neměl. Takže kdo potřeboval zapisovat — třeba jen komentáře — sáhl po Power Apps. Formulářové aplikace, které uměly zapsat do libovolné destinace. Nicméně Power Apps má pro mě strmou křivku učení. A licenční model? SharePoint list byl zdarma. Přímý zápis do SQL databáze byl placený konektor.

Translytical Task Flows: writeback přímo z Power BI

Paralelně s tím přišly Translytical Task Flows — Power BI funkcionalita, která ve spolupráci s User Data Functions (UDF) ve Fabricu umožňuje writeback přímo z Power BI prostředí. Pojmenování je trochu chaos, protože ve stejnou dobu vyšly i User Defined Functions v DAXu — a obojímu se říká UDF. Interně si to rozlišujeme jako UDFA (Fabric item) vs. UDFX (DAX).

UDF je v podstatě libovolný Python kód — typicky právě zápis zpět do zdroje. Uživatel klikne na řádek v reportu, napíše komentář do textového pole, a během vteřiny je to v databázi. Není to jako klikat přímo do buňky v Excelu. Je to textové pole, které je furt na stejném místě bez ohledu na to, kde kliknete. Ale je to nejbližší věc, co Power BI momentálně nabídlo — a pro komentáře nebo jednoduché přírůstky to funguje.

Fabric Planning: tabulka, do které se konečně dá psát

Plan item je nový item ve Fabricu, který vypadá a chová se jako Excel. Máte tam pivotku, do které se kliká. Pojem buňka existuje. Připojíte se na existující sémantický model, data jsou živá, a více lidí se dívá na stejné místo. Žádné sdílené excely na SharePointu, žádné posílání příloh mailem.

Plan item nabízí tři typy sheetů:

• Planning sheet — klasický forecasting a budgeting. Připojíte se na sémantický model, vykonstruujete pivotku, a v režimu scénáře přepisujete čísla. Ta reálná data v pozadí se nemění — scénář je váš sandbox.
• Power Table sheet — správa master dat. Typický příklad: kurzovní lístek. Britská pobočka plánuje v GBP, konsolidace je v EUR — Power Table sheet to umí vzít v potaz.
• Intelligence sheet — vizuální vrstva přímo v Plan itemu. Waterfally, progress bary, grafy scénářů. Teoreticky nemusíte výsledky exportovat do Power BI reportu — je to integrovaný frontend.

Writeback: kam a kolik řádků to vygeneruje

Writeback v Plan itemu slouží k uložení naplánovaných dat pro další komponenty — sémantický model, pipeline, reporting. Aktuálně jde writeback pouze do SQL databáze ve Fabricu. Lakehouse ani warehouse zatím ne.

Jak se data zapíší závisí na zvoleném módu:

• Long (default) — 1 řádek za 1 buňku. Pokud máte rok, měsíce a 10 produktů, tak to vynásobte. Hodně řádků. Stejný princip jako historická alokace v multidimenzionálu.
• Wide — sloupcový formát, méně řádků. Atributy se stanou sloupci. Víc připomíná strukturu pivotky.
• Long with changes — přidává preview value a latest value k každé změně. Máte historii, ale i víc dat.

Co to vlastně stojí

Podle dokumentace Plan item sám o sobě nic nestojí — Microsoft za něj neúčtuje žádné extra CU ani licence. Realita na pozadí je ale trochu jiná.

Celá pravda: každý Plan item automaticky vyrobí Fabric SQL Database, která ukládá veškerá metadata a operace. SQL databáze zadarmo není. Vojta si měřil hodinu aktivního klikání a vrtění v Plan itemu — řádově 1 000 CU. Na F2 kapacitě máte denní budget 172 800 CU (86 400 sekund × 2). Hodina plánování denně je tedy zhruba 0,5 % denního budgetu.

K tomu přičtěte, že SQL databáze dotáčí CU ještě nějakou dobu po operaci — reálně to může být 15–20 000 CU i víc. Výsledek: nezruinuje vás to. Ale není to zadarmo. A pro planning, který probíhá typicky v špičkách — jednou za měsíc nebo za kvartál — dává smysl kapacitu při potřebě škálovat nahoru a po skončení planningového cyklu zase dolů.

Formula language a trochu byznysu okolo

Jazyk formul v Plan itemu je prakticky Excel. IF, SUM, COUNT — nic nového. Jedna drobnost, která ale plannery potěší: pokud chcete zvýšit hodnotu o 9 %, napíšete +9 %. Systém si to přepočítá sám. Nemusíte si pamatovat, že to je ×1,09. Ocení to i lidé, kteří trojčlenku ovládají, ale radši ji neřeší.

Kontext, jak Planning vůbec vznikl: Microsoft tuhle funkcionalitu nenaprogramoval od nuly. Integroval řešení firmy Lumel (přibližně 400 zaměstnanců), která historicky dodávala custom vizuály pro writeback a plánování v Power BI. Nešlo o akvizici — šlo o partnerství, kde Lumel integroval svůj produkt přímo do Fabricu. Výhoda pro obě strany: Microsoft nabídne nativní plánovací nástroj jako součást platformy, Lumel neřeší procurement a certifikační procesy u každého zákazníka zvlášť. Pokud jste někdy zažili debatu s nákupním oddělením o schválení nástroje třetí strany, tak víte, proč to byl pro obě strany no-brainer.

Preview a jak to zapnout

Plan item je aktuálně v preview. Defaultně vypnutý — musíte ho explicitně zapnout v admin portálu. Po zapnutí počítejte se zpožděním 15–20 minut, než se aktivuje. Dostupnost závisí na regionu. West Europe funguje — Vojta testoval. Pokud máte tenant jinde, ověřte si seznam podporovaných regionů v dokumentaci předtím, než zákazníkovi slíbíte demo.

Závěr

Dnešní post vám měl ukázat cestu od historického SSAS writeback přes Power Apps a Translytical Task Flows až po Fabric Planning. Je to první nativně integrovaná odpověď v Power BI ekosystému na otázku z controllingu, která mě provází od začátku kariéry.

Celou historii jsme s Vojtou Šímou probrali v podcastu Cesta do Fabricu — pokud dáváte přednost mluvenému slovu, poslechněte si ho tam.

Gen AI a Power BI layout: kdo si poradí a kdo se vymlouvá?

Na Power BI Day 2026 jsem poprvé oddemoval živě využití Claude pro úpravu layoutu ve stávajícím Power BI reportu. 

Princip jednoduchý. 

1. Uložit stávající soubor (vytvořený 2016) jako pbip. Rozložení do složkové struktury a lepší čitelnost pro agenta. Ze semantického modelu vykostit cache.abf. Ta je zde stejně k ničemu a zbytečně nafukuje soubor. Nechci ani nikam dávat data. 
2. Soubor zazipovat, hodit screenshot s layoutem a popsanými úpravami do vašeho oblíbeného chatbota (v mém případě Claude Opus 4.6 extended thinking).
3. A zadat prompt s úpravami.

Původní layout

Co chci změnit? Aktuální velikost stránky 720x960, lišta se slicery je vlevo (nejprominentnější místo celého reportu). Chci změnit velikost stránky na full HD. Slicery dát doprava, zbytek posunout doprava. Využít celý prostor, upravit fonty. A to pro všechny stránky. Vrátit jako zip.

Můj prompt

Claude na první dobrou přišel s logickými kroky a začal implementovat. Následně stačilo rozbalit zip. Překopírovat Report složku v PBIP a nahradit v původní lokaci.

Výsledek na první iteraci? Fonty by mohly být větší, ale zvládl to pro všechny stránky.

Častá otázka zněla, jestli to zvládnou ostatní modely od jiných providerů. Rozhodl jsem se tedy pro souboj titánů. Stejné instrukce, top extended thinking model. Vzhledem k tomu, že si je všechny platím, tak by měření nemělo být zkresleno slabším modelem v neplacené verzi.

Microsoft M365 Copilot

Seknul jsem se na uploadu ZIPu. Stejný problém se standalone Copilot. Lehké zklamání.

Gemini 3 thinking a 3.1 PRO

Mi oba smažou zip soubor a přesvědčují, že jsou jen AI, a proto nemůžou přímo modifikovat JSONy.

Na otázku, zda používám ten stejný tool z Gemini ekosystému, přichází s plánem, že si můžu struktury nachystat ručně a pomůže mi potenciálně s Pythonem. Nějak si to nedokážu představit a jsem popravdě zklamán. S Gemini to není poprvé, co se vymlouvala, že něco nedokáže. Možná ale nepoužívám správným způsobem, nebo prostě není vhodný kandidát na tento typ úlohy.

ChatGPT 5.4 Thinking

Trvalo to 6 minut 27 sekund. Ale ChatGPT vrací zip soubor.

Změnil sice rozložení, ale ne velikost stránky.

Po mé stížnosti v iteraci 2 se omluví a provede to, co jsem chtěl. Posune slicery na všech stránkách. 

Logo a hodinu, do kdy jsou aktualizovaná data, nechal na místě, stejně tak svislou modrou čáru. Byl jsem pro ChatGPT málo specifický.

Ve třetí iteraci, kdy mu explicitně vyznačuji, kterou část chci posunout, nechá vlevo bílé místo a je zbytečně kreativní.

Na čtvrtou iteraci nemám nervy a při psaní tohohle článku už ani čas. 

Závěr

Pro úpravy vizuální stránky reportů ze zazipovaného PBIP projektu u mě vítězí Claude, který si s tím poradil na jedničku na první dobrou. Na druhou stranu Clauda na podobné typy úloh používám často a přestože jsem měl samostatnou konverzaci, mohl využít paměť z projektů bokem. To nejsem schopen vyloučit. 

ChatGPT nehodil flintu do žita a odvedl nějakou práci. Na několik iterací se postupně zlepšoval a věřím, že bych s ním došel do úspěšného cíle, pokud bych v iteracích pokračoval. Může to být též ovlivněno, že jej nepoužívám na práci s Power BI soubory, a tudíž nemá vybudovanou paměť (opět mimo projekt). 

Gemini mě popravdě zklamalo, vymlouvá se, že je jen AI a tohle nemůže, a maže mi soubor. Dostal jsem se ale alespoň k odeslání promptu, což je dál než Copilot, kde maže zip soubor hned a ani k tomu promptu se nedostanu. 

Určitě bych mohl stejnou úlohu řešit přímo z VS Code pomocí GitHub Copilota (nebo Cursor), který by to stoprocentně dal (v závislosti na vybraném modelu). Ale to nebylo účelem tohohle cvičení. Cílem bylo porovnat masově rozšířené Gen AI aplikace od mainstream providerů. 

To, že Gemini s Copilotem vyignorovaly tento typ úlohy, ještě neznamená, že jsou špatné AI, jen jsou jinam cílené.

U mě osobně tedy pro tyto typy úloh vychází Claude, a to i pro úlohy ve VS Code GitHub Copilot.

A ještě důležitá poznámka na závěr – co platí dnes, nemusí platit zítra. V dynamicky se vyvíjejícím AI světě se situace mění doslova z měsíce na měsíc. Takže berte tohle jako snapshot stavu v březnu 2026.