Ez a kérdés két-három éve viccnek hangzott, ma pedig komoly tervezési döntés. A szemantikus modellek létrehozása és szerkesztése általánosan elérhetővé vált a Power BI szolgáltatásban, a 2026 júliusi kiadás pedig két olyan dolgot hozott, ami eddig egyértelműen Desktop-terep volt: a Model options dialógust és a TMDL nézetet – vagyis a modell szöveges, kódszerű megjelenítését – a weben. Ha valaki csak a bejelentéseket olvassa, könnyen arra jut, hogy a Desktop napjai meg vannak számolva. A gyakorlat ennél árnyaltabb, és a különbség pont ott van, ahol a legtöbb csapat nem számol vele.
Amit a böngésző ma tud
A böngészőben szerkeszthetők a mérőszámok, átnevezhetők a táblák és oszlopok, kezelhetők a kapcsolatok, beállítható a soralapú biztonság (RLS) és a frissítési ütemezés. Ehhez jött júliusban a Model options, amivel modellszinten szabályozható a típusfelismerés, a kapcsolatok automatikus detektálása, az időintelligencia, a párhuzamos betöltés és a területi beállítás, valamint az, hogy más szemantikus modellek DirectQueryvel csatlakozhatnak-e ehhez a modellhez. 2026 augusztustól a modellbeállítások is új helyre kerülnek: a teljes beállítási oldal helyett egy oldalpanel nyílik a tartalom mellett, tehát a frissítési ütemezés vagy a hitelesítő adatok módosításához nem kell elhagyni a munkaterületet.
Van egy praktikus mellékhatása is ennek a fejlődésnek. Aki eddig virtuális gépen, távoli asztalon vagy kettős rendszerindítással futtatta a Desktopot – jellemzően Mac-en –, annak ez nem apró kényelmi javulás, hanem a munkafolyamat teljes átrendeződése. És megszűnik a publikálás-újrapublikálás ciklus is, ami verziókonfliktusokat és lassú iterációt eredményezett.
Ahol a böngésző megáll
Ez az a rész, amit a kiadási összefoglalók nem hangsúlyoznak. A Power Query-s átalakítás és az új adatforrás-kapcsolat a weben kizárólag import tárolási módban működik, Direct Lake és DirectQuery táblákon nem – ami önmagában eldönti a kérdést sok Fabric-alapú környezetben, ahol épp a Direct Lake a fő tárolási mód. Ugyanezekben az esetekben a webes szerkesztő frissítés gombja is le van tiltva: Direct Lake, DirectQuery és összetett modelleknél, valamint ott, ahol egyedi konnektor vagy kockaadatforrás van a képben.
A konnektorlista is szűkebb. Import táblák hozzáadása a weben nem támogatott egyedi konnektorokkal, sem Azure Database for PostgreSQL, IBM Informix, Essbase, Microsoft Exchange, Hadoop File (HDFS), OLE DB, R és Python forrásból – a Desktop ebben továbbra is a legszélesebb tölcsér. A tábla tárolási módjának megváltoztatása a szolgáltatásból szintén nem megy; ezt a Power BI szemantikus modellekért felelős programmenedzsere maga is elismerte egy 2026-os júniusi beszélgetésben, több más hiányzó dialógussal együtt.
Egy részlet pedig menet közben szokott kellemetlenül előjönni: ha a szerző a szolgáltatásban Power Queryvel importál adatot, a forrásrendszerből származó kapcsolatok nem feltétlenül töltődnek ki automatikusan, tehát azokat kézzel kell kialakítani és karbantartani. Ez megnöveli a fejlesztési időt, és növeli a modellezési következetlenségek kockázatát. A riportkészítés oldalán is maradtak hiányosságok: a könyvjelzők kezelése, a vizuális elemek és hátterek rétegeinek kiválasztása, valamint a szeletelők szinkronizálása a szolgáltatásban ma is problémás.
A helyes kérdés nem az, hogy „vagy”
A gyakorlatban nem arról érdemes dönteni, hogy Desktop vagy böngésző, hanem arról, hogy melyik munkafolyamathoz melyik. A böngésző erőssége a gyors, célzott módosítás: egy mérőszám javítása, egy elnevezés rendbetétele, egy kapcsolat pótlása, egy RLS-szabály módosítása. Ezekhez ma nincs értelme Desktopot indítani, kicsomagolni egy .pbix fájlt, majd újrapublikálni – ez a ciklus önmagában hibaforrás volt.
A Desktop viszont továbbra is az elsődleges hely, ahol import és DirectQuery modell születik, ahol a teljes konnektorkészlet elérhető, és ahol az összetett Power Query-logika kényelmesen megírható. Direct Lake modelleknél más a helyzet: azok a munkaterületen élnek és ott szerkesztődnek, nem lokális .pbix fájlként, tehát a komolyabb sémamunkához és metaadat-vizsgálathoz XMLA-kompatibilis eszközökre érdemes váltani, például SSMS-re vagy Tabular Editorra. Van ezen felül egy harmadik réteg is, amiről kevés szó esik: ha a modell verziókövetés és CI/CD alá kerül, a PBIP formátumú export teszi lehetővé a Git-integrációt. Ez a szint egyik felületen sem kattintható – ez már mérnöki munkafolyamat.
Mit érdemes ebből eldönteni
A döntést nem a preferencia hozza meg, hanem a tárolási mód. Ha a környezet Direct Lake-re épül, a webes modellezés jelentős része eleve nem alkalmazható, és ez nem fog jövő hónapban megváltozni. Ahol viszont import modellek dominálnak, ott a böngésző ma már lefedi a napi munka nagyobbik részét.
Arra viszont nem érdemes belső szabályzatot építeni, hogy pontosan mi hiányzik ma a webes felületről, mert az a lista hónapról hónapra rövidül. Ami most csak Desktopon megy, arról fél év múlva nem biztos, hogy igaz lesz. Sokkal tartósabb, ha a szabály szerepekhez és munkafolyamatokhoz kötődik: ki nyúlhat a modellhez, milyen típusú változtatás után kell jóváhagyás, és hol keletkezik a verziótörténet. A valódi kockázat ugyanis nem a hiányzó funkció, hanem a szétcsúszó gyakorlat – ha a csapat egyik fele böngészőben szerkeszt, a másik fele Desktopon, és nincs megállapodás arról, mi hol történik, néhány hónap alatt keletkezik egy olyan modell, aminek a történetét senki nem tudja rekonstruálni.
A címben feltett kérdésre tehát egyelőre az a válasz, hogy igen, kell – de már nem mindenkinek és nem mindenhez. Ez pedig önmagában nagyobb változás, mint amilyennek látszik: eddig a Desktop volt a belépő, most inkább az a hely, ahová a nehéz munkáért megy az ember.
Ha egy szervezetben most nem világos, ki mit hol szerkeszt, azt érdemes rendezni, mielőtt a modell mérete és a szerzők száma is nő. Nem eszközválasztási kérdés – inkább egy fél napos megállapodás arról, hogy melyik változtatás melyik felületen és milyen jóváhagyással történik.
