BI-Publish Deep Dive

Begriffe vor dem Lesen

• Publish — Freigabe und Bereitstellung eines BI-Produkts für Nutzung.
• Workspace / Stage — Arbeits- oder Veröffentlichungsbereich für Entwicklung, Test und produktive Nutzung.
• Refresh — Aktualisierung von Datenmodell, Kennzahlenmodell oder Reportdaten.
• Berechtigung — Berechtigung, welche Person welche Daten oder Flächen nutzen darf.
• RLS / OLS — Row-Level- und Object-Level-Security; Zugriff auf Zeilen oder Objekte im BI-Modell.

Produkte und Entscheidungen

Die Landschaft braucht nicht „einen Tenant sauber“, sondern geschnittene Publish-Produkte.

Publish-Vertrag

Dieses Produkt beschreibt:

• Artefakt-Typ (Workspace / App / semantisches Modell / Report); erlaubte Stage; wer heben darf; welcher fachliche verantwortliche Person die Freigabe trägt; Review-Datum.

Entscheidungen:

• Welche Artefakte dürfen in Produktion stehen?; Wer ist A für Heben vs. A für Bedeutung?; Wann ist ein Personal-Publish ein Incident?

Stage-Register

Dev, Test, Prod — oder Personal, Shared, zertifiziert — als Gate, nicht als Ordnerfarbe.

Entscheidungen:

• Welche Stage darf Board-Packs speisen?; Welcher Negativtest gilt vor Produktfreigabe?; Wer darf Stage-Zwecke umbenennen?

Refresh- und Reduktion-Anschluss

Refresh und wer die Zeile sieht gehören zum Publish, nicht als Nachgedanke.

Entscheidungen:

• Wer besitzt Credentials und Gateway?; Welche Matrix erzwingt die App — und wo ist sie System of Record?

Wo Governance hängt

Zwischen Workspace-Administrator und Data Owner

Admin-Rechte am Workspace sind Custodian-Arbeit. Semantik, Zweck und Freigabe bleiben beim fachlichen Owner.

Zwischen Zertifizierungslabel und Kennzahlvertrag

Endorsement macht auffindbar. Grain, Population und Evidence leben im KPI-Vertrag, nicht im Badge.

Zwischen Personal Speed und Board-Pack

„Nur schnell teilen“ wird zur Wahrheit, sobald Steuerung denselben Link öffnet.

Zwischen Tenant-Setting und Policy

Ein Tenant-Häkchen ist keine Zweckbindung, keine Retention und keine Rezert der Reduktion.

Zwischen App, Workspace, Semantic und Report

Vier Objekte, oft ein Name. Ohne Typ im Vertrag promoviert das falsche Artefakt.

Zwischen Refresh-Stille und Decision Cadence

Ein grünes Badge auf gestrigen Zahlen ist kein Operating.

Rollen-Mapping

Data Owner (Fachlichkeit)

Head of Finance oder benannter Process Owner gibt Bedeutung, Nutzung und Promotion in den Board-Kreis frei. Layout und Workspace-Rechte sind nicht dieses A.

Data Steward

Triagiert Publish-Incidents, pflegt das Stage-Register, eskaliert Personal-zu-Prod-Drift.

Data Product Owner

Priorisiert, welches Semantic oder welche App den Veröffentlichungspfad zuerst bekommt. Nutzen und Lieferbarkeit — nicht die fachliche Definition.

Data Architect

Schützt Artefakt-Typen und Lineage Mart → Semantic → App. Breaking Changes an Consumer-Schnittstellen.

Data Custodian

BI-Admin und Plattformbetrieb setzen Workspace, Gateway, Labels und fail-closed Durchsetzung um. Lizenzverwaltung ist keine Semantikhoheit.

Report- / BI-Builder

Liefern Thin-Consumers auf dem freigegebenen Pfad. Sie heben nicht still von Personal nach Prod.

Mini-Fall

Symptom: Der Nettoumsatz ist in einer freigegebenen Auswertungstabelle definiert. Der Vorstand liest aber einen Bericht aus einem persönlichen Arbeitsbereich. Ein anderes semantisches Modell trägt das Label „zertifiziert“. Drei Apps zeigen unterschiedliche Regionen.

Typischer Fehlstart: Tenant-Zertifizierung einschalten und alle Produktions-Workspaces als „governed“ labeln, ohne Stufen-Prüfpunkt, ohne Aktualisierungsverantwortung und ohne führende Berechtigungsmatrix.

Vereinbarung: Ein Veröffentlichungspfad für ein semantisches Modell und eine App; Stufen-Prüfpunkt vor Board; technischer Betreiber setzt um; Data Owner gibt frei; Reduktion kommt aus dem Berechtigungsprodukt.

Kritische Übergaben

Anti-Patterns

• Workspace-Administrator als Data Owner behandeln
• Zertifizierungslabel ohne fachliche Ebene, Owner und Nachweis
• Personal Workspace als Produktion-Quelle für Steuerung
• Tenant-Setting mit Richtlinie verwechseln
• App, Workspace, semantisches Modell und Report in einem „Ordner“ mergen
• Refresh und Reduktion erst nach dem Launch klären

Umsetzung im Alltag

Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — BI-Publish Deep Dive
• Lernpfad — BI-Publish Deep Dive

1. Ein Semantic und eine App wählen, die bereits steuern.
2. Publish-Vertrag schreiben: Stage, Artefakt-Typ, A für Heben, A für Bedeutung.
3. Personal- und Prod-Kopien inventarisieren; Board-Quelle benennen.
4. Refresh-Owner und Reduktion-Quelle in einem Satz festhalten — Vertiefung in Teil 3–5.

Exit-Kriterien

• Vorstandsbericht speist nur aus einem benannten Stage-Artefakt.
• Workspace-Administrator ist technischer Betreiber, nicht Data Owner.
• Zertifizierungslabel verweist auf einen Kennzahlvertrag, ersetzt ihn nicht.
• Produktfreigabe Personal/Dev → Produktion braucht Antrag und Freigabe durch die verantwortliche Person.

Weiterlesen

• Nutzer-Stufen und gemeinsames Modell
• Gemeinsames Modell für alle Nutzer-Stufen
• Kennzahlenmodell vs Kennzahl im Report
• Fabric / Power BI Metric Certification
• Berechtigungsmatrizen und Section Access
• Dashboard Design Operating Checklist
• Dashboard- und Report-Design Deep Dive

Begriffe vor dem Lesen

• Publish — Freigabe und Bereitstellung eines BI-Produkts für Nutzung.
• Workspace / Stage — Arbeits- oder Veröffentlichungsbereich für Entwicklung, Test und produktive Nutzung.
• Refresh — Aktualisierung von Datenmodell, Kennzahlenmodell oder Reportdaten.
• Berechtigung — Berechtigung, welche Person welche Daten oder Flächen nutzen darf.
• RLS / OLS — Row-Level- und Object-Level-Security; Zugriff auf Zeilen oder Objekte im BI-Modell.

Ein Workspace mit „Prod“ im Namen ist kein Gate. Promotion hebt ein benanntes Artefakt — App, Semantic oder Report — mit Owner-Entscheidung. Copy-Paste aus dem Personal Workspace ist Drift.

In der Praxis zeigt sich das so: Das Board liest in Power BI 12,4 Mio. Nettoumsatz aus dem Personal-Workspace, weil der Ordner „Prod“ voll ist. Der Name der Stage steuert — nicht eine Freigabe.

Dieser Teil bindet Stage an Artefakt-Typ, bevor Refresh und Reduktion darauf aufsetzen.

Vorher: Warum BI-Publish Governance bricht. Weiter: Refresh, Gateway und Credential-Verantwortung.

Entscheidung

Führen Sie ein Stage-Register und eine Artefakt-Typ-Liste.

1. Typen trennen — Workspace (Kollaboration), App (Consumer-Paket), Semantic / Dataset (Berechnungsvertrag), Report (Darstellung). Ein Name für alle vier ist das Anti-Pattern.
2. Stage-Zweck — Personal/Dev: Bau; Shared/Test: Abnahme; Prod/zertifiziert: Steuerung. KMU dürfen zwei Stufen fahren (Bau vs. Steuerung), nicht null.
3. Promotion-Gate — Antrag (Scope, Zielstage, Consumer), Steward-Triage, Data-Owner-Freigabe für Board-Kreis, Custodian-Deploy. Ein zertifiziert Dataset-Badge ohne diesen Lauf ist UI.
4. Negativtest — nach dem Heben darf der Personal-Link nicht weiter steuern; alte App-Version fail-closed oder als deprecated gelabelt.
5. Hüte — Data Owner gibt Board-Speisung frei; Steward führt das Register; Custodian setzt Workspace-Rechte und Pipelines um; Builder beantragen, sie klicken nicht still.

Fabric Deployment Pipelines, Tableau projects und Qlik spaces sind Adapter für dasselbe Gate — nicht drei Governance-Modelle. Vendor-Start bleibt Microsoft Fabric als Governance-Einstieg; Metric-Badges bleiben Fabric / Power BI Metric Certification.

Promotion-Workflow

1. Artefakt inventarisieren

Custodian listet Workspace, App, Semantic und Report getrennt, mit Stage und Owner. Wer nur Workspaces zählt, promoviert das falsche Objekt.

2. Gate veröffentlichen

Steward schreibt: welche Stage darf den Board-Pack speisen, wer beantragt, wer A ist. Ohne Gate entscheidet der letzte Share-Link.

3. Antrag und Freigabe

Builder beantragen Heben mit Zielstage und Consumer. Data Owner gibt frei, wenn der Kennzahlvertrag gilt. Steward lehnt stilles Copy-Paste ab.

4. Deploy und Negativtest

Custodian hebt nur das beantragte Artefakt. Test: Personal- oder Dev-Kopie steuert nicht weiter. Pipelines, die den ganzen Workspace als Einheit behandeln, brauchen eine Typ-Checkliste.

5. Drift eskalieren

Prod-Artefakt ohne Vertrag oder Board auf Personal ist ein Incident an den Steward, nicht ein Aufräumticket in drei Monaten.

Handoffs

Anti-Patterns

• Personal Workspace als Produktion, weil die Pipeline fehlt
• Ganzen Workspace heben, obwohl nur ein Report beantragt war
• Zertifizierungslabel als Ersatz für Freigabe durch die verantwortliche Person
• Tableau-Project, Qlik-Space und Fabric-Workspace als drei Richtlinien ohne gemeinsames Prüfpunkt
• App-Rechte mit semantisches Modell-Verantwortung verwechseln

Umsetzung im Alltag

Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

• Arbeitsplan — BI-Publish Deep Dive
• Lernpfad — BI-Publish Deep Dive

1. Ein Semantic und eine App in einer Typ-Liste führen (nicht nur den Workspace).
2. Board-Quelle auf Prod/zertifiziert legen oder den Ist-Zustand als Incident markieren.
3. Ein Promotion-Gate für den nächsten Hebe-Vorgang fahren (Antrag, A, Negativtest).
4. Personal-Shares inventarisieren, die noch steuern.

Begriffe vor dem Lesen

• Publish — Freigabe und Bereitstellung eines BI-Produkts für Nutzung.
• Workspace / Stage — Arbeits- oder Veröffentlichungsbereich für Entwicklung, Test und produktive Nutzung.
• Refresh — Aktualisierung von Datenmodell, Kennzahlenmodell oder Reportdaten.
• Berechtigung — Berechtigung, welche Person welche Daten oder Flächen nutzen darf.
• RLS / OLS — Row-Level- und Object-Level-Security; Zugriff auf Zeilen oder Objekte im BI-Modell.

Ein zertifiziert-Report auf gestrigen Zahlen ist kein Operating. Refresh braucht ein SLO (wie frisch die Zahl sein muss), ein A für Credentials und ein On-Premises Gateway als Betrieb — nicht den Laptop des Builders.

In der Praxis zeigt sich das so: Der zertifiziert Power-BI-Report zeigt 12,4 Mio. Nettoumsatz von gestern, weil das Gateway auf dem Laptop des Builders hing.

Dieser Teil hängt den Datenpfad an den Publish-Vertrag aus Teil 1 und 2.

Vorher: Workspace, Stage und Promotion-Gates. Weiter: BI erzwingt die Berechtigungsmatrix.

Entscheidung

Binden Sie drei Felder an jedes Prod-Artefakt, das steuert:

1. Refresh-SLO — Kadenz, erlaubte Verspätung, was bei Bruch gilt (Board pausiert / letzte gültige Periode / Incident). Ohne SLO ist „täglich“ ein Wunsch.
2. Credential-Owner — benannte Identität (Dienstkonto), Rotation, kein Chat-Secret. Der Builder ist nicht das Konto.
3. Gateway-Betrieb — Cluster oder Plattform-Gateway mit Custodian-A; persönliches Gateway nur für Dev, nie für Board. High availability ist Betrieb, kein Nice-to-have, sobald Steuerung hängt.
4. Fail-sichtbar — stale oder fehlgeschlagen muss im Consumer-Kontext erkennbar sein, nicht nur im Admin-Portal.
5. Hüte — Custodian betreibt Gateway und Konto; Steward triagiert Refresh-Incidents; Data Owner entscheidet, ob das Board bei Bruch pausiert.

Qlik Reloads, Tableau Extracts/Bridge und Fabric/Power-BI-Refresh sind Adapter. Dasselbe A, dieselbe Stop-Regel.

Refresh-Workflow

1. SLO am Artefakt festhalten

Steward schreibt Kadenz und Bruchregel in den Publish-Vertrag. „Irgendwann nachts“ ist kein SLO.

2. Konto vom Menschen trennen

Custodian führt das Dienstkonto. Rotation und Vault gehören zum Betrieb. Ein persönliches OAuth-Token als Prod-Refresh ist ein Incident.

3. Gateway aus der Bau-Zone holen

Persönliches Gateway darf Dev speisen. Prod braucht betriebenes Gateway oder Plattform-Refresh ohne Laptop. Urlaub des Builders darf den Close nicht stoppen.

4. Bruch als Incident

Fehlschlag oder Überschreiten des SLO öffnet ein Ticket an Steward plus Consumer-Hinweis. Stille Wiederholung „bis es wieder geht“ züchtet Board auf Gestern.

5. Evidence

Letzter erfolgreicher Lauf, Konto, Gateway-Knoten, Owner. Ein Screenshot ohne Zeitstempel ist keine Evidence.

Handoffs

Anti-Patterns

• Laptop-Gateway als Produktions-führendes System
• Passwort im Team-Chat oder in der Kennzahl-Datei
• Zertifizierungslabel bei gerissenem Refresh
• Builder als einziges Credential-A
• Gateway-Ausfall erst am Close-Morgen entdecken, ohne Nutzer-Hinweis

Umsetzung im Alltag

Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

• Arbeitsplan — BI-Publish Deep Dive
• Lernpfad — BI-Publish Deep Dive

1. Für das Board-Semantic Refresh-SLO und Credential-Owner in einem Satz schreiben.
2. Persönliche Gateways an Prod-Artefakten inventarisieren und umziehen oder als Incident markieren.
3. Einen fehlgeschlagenen Lauf als Incident inkl. Consumer-Hinweis üben.
4. Chat-Secrets durch ein Dienstkonto ersetzen.

Begriffe vor dem Lesen

• Publish — Freigabe und Bereitstellung eines BI-Produkts für Nutzung.
• Workspace / Stage — Arbeits- oder Veröffentlichungsbereich für Entwicklung, Test und produktive Nutzung.
• Refresh — Aktualisierung von Datenmodell, Kennzahlenmodell oder Reportdaten.
• Berechtigung — Berechtigung, welche Person welche Daten oder Flächen nutzen darf.
• RLS / OLS — Row-Level- und Object-Level-Security; Zugriff auf Zeilen oder Objekte im BI-Modell.

Row-Level Security in der App filtert Regionen. Wenn dieselbe Matrix nur im Dataset, im Tableau-Filter und im Qlik-Skript lebt, sind drei Reduktions (drei Antworten auf „welche Zeilen sieht diese Person?“) drei Wahrheiten — auch wenn IAM-Rezert grün ist.

In der Praxis zeigt sich das so: Dieselbe Region-Leitung sieht in Power BI 12,4 Mio. Nettoumsatz, in Tableau 9,1 Mio. — die RLS-Zeile und der User-Filter meinen verschiedene Keys.

Dieser Teil hängt Durchsetzung an den Veröffentlichungspfad. Das System of Record bleibt das Berechtigungsprodukt in Berechtigungsmatrizen und Section Access gehören in die DB. Access-Policy-Rahmen: Access Security Governance.

Vorher: Refresh, Gateway und Credential-Verantwortung. Weiter: RLS, OLS und Tool-Reduktion-Maps.

Entscheidung

Trennen Sie Produkt und Durchsetzung am Publish:

1. führendes System — Berechtigungsprodukt mit Business Keys (company_code, region_id), Owner, Gültigkeit, Rezert-Evidenz. Pflege in der DB, nicht in drei App-Skripten. Vertiefung: Control-Data Teil 9.
2. Durchsetzung — die Prod-App lädt die Consumer-View und filtert. Power BI RLS/OLS, Tableau User Filter, Qlik Section Access, Looker access grants sind Adapter.
3. Fail-closed — fehlt die Matrix oder ist sie stale, öffnet die App nicht zu weit. Ein hartcodierter ADMIN-Bypass in Prod ist ein Incident.
4. IAM ≠ Reduktion — Gruppen-Rezert bestätigt Identität und Rolle. Sie bestätigt nicht, welche Company-Zeile die App zeigt.
5. Hüte — Control Owner / Steward pflegt die Matrix; Data Owner gibt Zweck und Population frei; Custodian verdrahtet den Load; Builder editieren keine Inline-Listen in Prod.

Dieses Teil erfindet die Matrix nicht neu. Es verbietet, Publish ohne Durchsetzung-Anschluss an das Produkt zu erklären.

Durchsetzung-Workflow

1. Quelle benennen

Steward schreibt in den Publish-Vertrag: welche Matrix-View diese App lädt. „RLS ist an“ ohne View-ID ist kein Anschluss.

2. Identity-Map explizit

IdP-User → analytische USERID gehört zum Produkt, nicht zu einer versteckten Excel-Spalte. Drift zwischen Entra-Gruppe und Reduktion-Zeile ist ein Incident.

3. Dual-Run vor Prod

Neue App oder neues Semantic vergleicht Reduktion gegen die kanonische Matrix, nicht gegen die Nachbar-App. Drei Apps, die sich gegenseitig kopieren, züchten denselben Fehler.

4. Rezert an der Zeile

IAM-Review plus Matrix-Review. Wer nur Gruppen abhakt, lässt Orphan-Reduktions stehen.

5. Incident

User sieht zu viel oder zu wenig gegen die Matrix: Ticket an Steward, nicht stiller Dataset-Hotfix.

Handoffs

Anti-Patterns

• Dataset-lokale RLS-Rollen als führende Wahrheit
• Rezertifizierung der Zugriffsverwaltung als Ersatz für Matrix-Zeilen
• Drei Reduktions, ein Label „Region“
• ADMIN-Zeile „vorübergehend“ im Skript
• Excel-USERID per Mail an Entwickler

Umsetzung im Alltag

Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

• Arbeitsplan — BI-Publish Deep Dive
• Lernpfad — BI-Publish Deep Dive

1. Für die Board-App die Matrix-Quelle in einem Satz nennen — oder als fehlend markieren.
2. Eine zweite App auf denselben Key prüfen: gleiche Reduktion oder Drift.
3. Einen fail-closed Test: Matrix weg → App öffnet nicht zu weit.
4. Inline-Listen in Prod inventarisieren. Adapter-Maps: Teil 5.

Begriffe vor dem Lesen

• A11y — Accessibility / Barrierefreiheit: Gestaltung, damit Inhalte auch mit Einschränkungen zuverlässig nutzbar bleiben.
• Publish — Freigabe und Bereitstellung eines BI-Produkts für Nutzung.
• Workspace / Stage — Arbeits- oder Veröffentlichungsbereich für Entwicklung, Test und produktive Nutzung.
• Refresh — Aktualisierung von Datenmodell, Kennzahlenmodell oder Reportdaten.
• Berechtigung — Berechtigung, welche Person welche Daten oder Flächen nutzen darf.
• RLS / OLS — Row-Level- und Object-Level-Security; Zugriff auf Zeilen oder Objekte im BI-Modell.

Dataset-lokale RLS- oder OLS-Rollen driften von der Warehouse-Policy, sobald jedes Tool seine eigenen Feldnamen pflegt. Ein Business Key, mehrere Consumer-Views — Mapping in versioniertem SQL oder Skript, nicht in einer stillen Excel-Formel.

In der Praxis zeigt sich das so: Dieselbe Person sieht in Power BI Region Nord und in Qlik REGION=N — Nettoumsatz 12,4 Mio. gegen 9,1 Mio. RLS filtert Zeilen; OLS blendet Objekte aus; beides ist kein zweites führende Berechtigungsmatrix.

Dieser Teil ist keine Microsoft-Learn-Anleitung. Er mappt Adapter auf denselben Vertrag aus Teil 4 und Control-Data Teil 9.

Vorher: BI erzwingt die Berechtigungsmatrix. Fläche vor Promotion: Dashboard- und Report-Design Deep Dive. Dashboard-Betrieb danach: Dashboard Design Operating Checklist.

Entscheidung

Bauen Sie eine Adapter-Karte, keine zweite Policy.

OLS blendet Tabellen oder Measures aus. Das ist Objekt-Sichtbarkeit, keine Regionen-Reduktion. Beide dürfen existieren; sie dürfen nicht dieselbe Entscheidung tragen.

Transformation kanonisch → Engine gehört in versioniertes SQL oder geskriptete Loads. Template-Upload nur mit Reject-Report und Freigabe vor Publish — nie ungesteuertes Excel als Leader. Identity-Map (IdP → USERID) bleibt owned.

Dual-Run: neue View gegen die kanonische Matrix, nicht gegen das Nachbar-Tool. Warehouse-Row-Policies und BI-Adapter müssen denselben Key meinen, sonst ist „die Datenbank ist sicher“ ein anderer Filter als das Dashboard.

Adapter-Workflow

1. Key einfrieren

Architect und Control Owner nennen den Business Key. Tool-Feldnamen sind Aliase.

2. Eine View je Engine

Custodian veröffentlicht die Consumer-View. Builder verdrahten Durchsetzung daran. Wer im Dataset eine zweite Rollentabelle anlegt, öffnet Drift.

3. OLS und RLS nicht mischen

Steward dokumentiert: welche Entscheidung Zeile vs. Objekt ist. Ein verstecktes Measure ist keine Company-Reduktion.

4. Test je Adapter

Negativtest: User ohne Key sieht nichts. Positivtest: User mit Key sieht genau die Matrix-Zeile. Screenshot der RLS-UI ohne Key-Nachweis ist keine Evidence.

5. Sunset lokaler Rollen

Dataset-Rollen, Workbook-Filter und Inline-SA, die nicht aus der View kommen, bekommen Expiry oder Incident.

Handoffs

Anti-Patterns

• Pro Dataset eine eigene RLS-Rollentabelle
• Tableau-Parameter als führende Reduktion
• LookML-Grant am Explore-Namen statt am Key
• OLS als Ersatz für Zeilen-Berechtigung
• Mapping in Excel mit Partial Commit
• Warehouse-Richtlinie und BI-Filter auf unterschiedlichen Keys

Umsetzung im Alltag

Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

• Arbeitsplan — BI-Publish Deep Dive
• Lernpfad — BI-Publish Deep Dive
• Weiter Operating: Dashboard Design Operating Checklist
• führende Berechtigungsmatrix: Kontrollregel-Data Deep Dive

1. Key für die Board-App nennen und die existierenden Tool-Feldnamen als Aliase listen.
2. Eine Engine-View (oder ein Skript) an die kanonische Matrix hängen.
3. Einen Negativtest fail-closed fahren.
4. Eine lokale Rollentabelle zum Sunset markieren.

Exit-Kriterien

• Produktion-Apps laden Reduktion aus einer benannten View, nicht aus Inline-Listen.
• Adapter-Karte existiert für die tatsächlich genutzten Tools — ohne Tutorial-Klon.
• Warehouse-Key und BI-Key sind derselbe Business Key.
• OLS und RLS sind getrennte Entscheidungen.

Weiterlesen

• Berechtigungsmatrizen und Section Access
• Access Security Governance
• Fabric / Power BI Metric Certification
• Dashboard Design Operating Checklist
• Dashboard- und Report-Design Deep Dive
• Microsoft Fabric als Governance-Einstieg