Power BI-Service: Alles inklusive

Power BI Service ist die cloudbasierte Plattform von Microsoft zum Teilen, Zusammenarbeiten und Interagieren mit Daten und Berichten. Betrachten Sie ihn als die Online-Begleitung zu Power BI Desktop. Während Analysten in Power BI Desktop (einer kostenlosen Windows-App) Datenmodelle erstellen und Berichte entwerfen, können Sie diese Berichte, Dashboards und Apps im Power BI Service ( app.powerbi.com ) mit anderen teilen und nutzen . In der Praxis führen Sie Ihre Datenbereinigung, Modellierung und Berichtsgestaltung in Desktop durch und veröffentlichen diese Inhalte dann im Service. Mit dem Service können Sie Berichte und Dashboards in einem Browser oder einer mobilen App anzeigen, automatische Datenaktualisierungen einrichten, Zugriff/Sicherheit verwalten und Inhalte in Apps bündeln. Kurz gesagt: Desktop dient zum Erstellen und Bearbeiten; der Service zur Verteilung, Zusammenarbeit und Nutzung (mit Endbenutzern).

• Power BI Desktop : Kostenlose PC-App. Es ist ein umfassendes Tool zur Datenmodellierung und Berichtserstellung. Sie verbinden Datenquellen, transformieren Daten, erstellen ein semantisches Modell und erstellen interaktive Berichtsseiten. Anschließend veröffentlichen Sie Berichte im Power BI-Dienst, damit andere sie nutzen können. Sie können Power BI kostenlos herunterladen:

  https://www.microsoft.com/en-us/power-platform/products/power-bi/desktop?WT.mc_id=Blog_Desktop_Update Monatliche Power BI-Updates und Informationen: https://powerbi.microsoft.com/en-us/blog/

  
  

• Power BI-Dienst : Cloudbasiert (SaaS). Hier können Sie und Ihr Team Berichte, Dashboards und Apps teilen, bearbeiten (in begrenztem Umfang) und nutzen. Sie können auch einfache Datenvorbereitungen durchführen und einfache Berichte direkt im Dienst erstellen, die meiste Arbeit erledigen Sie jedoch auf dem Desktop. Im Dienst konfigurieren Sie außerdem die Zusammenarbeit (Arbeitsbereiche), die Sicherheit (Berechtigungen, Zeilenfilter) und stellen gepackte Inhalte (Apps) für Endbenutzer bereit.

Das Verständnis dieser Unterschiede hilft, Verwirrungen beim Erstellen oder Aktualisieren eines Datenmodells oder Berichts mit Desktop zu vermeiden. Das Veröffentlichen, Freigeben oder Interagieren mit Inhalten in der Cloud ist die Aufgabe des Power BI-Dienstes.

Power BI environment, Desktop for development, Service for sharing and Mobile for easy access to the reports

Kernkonzepte: Arbeitsbereiche, Datensätze, Berichte, Dashboards und Apps

Der Inhalt des Power BI-Dienstes ist in einige Hauptteile gegliedert. Stellen Sie sich jedes Teil als einen einzelnen Baustein im BI-Gebäude vor:

• Arbeitsbereich: Ein Arbeitsbereich ist wie ein gemeinsamer Ordner oder Projektbereich. Designer/Entwickler verwenden Arbeitsbereiche, um verwandte Inhalte (Datensätze, Berichte, Dashboards usw.) zu speichern und zu verwalten. Jeder Arbeitsbereich verfügt über Mitglieder mit Rollen (Administrator, Mitglied, Mitwirkender, Betrachter), die ihre Berechtigungen steuern. Jeder Arbeitsbereich befindet sich in Ihrem Power BI-Mandanten ( app.powerbi.com ) und kann für Abteilungen, Projekte oder jedes beliebige Team erstellt werden.

• Dataset (Semantisches Modell): Dies ist das Datenmodell, das Ihre Berichte unterstützt. Es kombiniert Daten aus einer oder mehreren Quellen in Tabellen und Beziehungen. In der Power BI-Sprache bedeutet „Dataset“ oft „Semantisches Modell“. Hier definieren Sie Tabellen, Beziehungen, Kennzahlen und Filter. Beispielsweise können Sie Umsatz- und Mitarbeiterdaten importieren und diese nach Mitarbeiter-ID verknüpfen. Das Semantische Modell bildet die Grundlage für Berichte und Dashboards.

• Bericht: Ein Bericht besteht aus einer oder mehreren Seiten mit visuellen Darstellungen (Diagrammen, Tabellen usw.), die auf einem einzelnen Datensatz basieren. Berichte sind interaktiv; Benutzer können Filter oder Slicer anklicken und die Visualisierungen detailliert betrachten. Jeder Bericht kann mehrere Seiten (Registerkarten) umfassen. Berichte werden in Power BI Desktop erstellt und anschließend im Dienst veröffentlicht. Bei Datenflüssen oder einfachen Datensätzen können sie sogar direkt im Dienst erstellt/bearbeitet werden.

• Dashboard: Ein Dashboard ist eine einseitige, pinnwandartige Leinwand mit visuellen Kacheln. Sie (oder andere Berichtsdesigner) pinnen visuelle Elemente (Diagramme, Karten, KPIs) aus Berichten an ein Dashboard an, um wichtige Kennzahlen auf einen Blick darzustellen. Führungskräfte oder Manager nutzen Dashboards häufig als zentrale Anlaufstelle für die Überwachung von Kennzahlen. Im Gegensatz zu Berichten sind Dashboards nur einseitig und enthalten in der Regel eine Mischung aus visuellen Elementen aus verschiedenen Berichten und Datensätzen. Durch Klicken auf eine Kachel gelangen Sie in der Regel zum zugrunde liegenden Bericht, um weitere Details anzuzeigen.

• App: Eine App in Power BI bündelt Dashboards, Berichte und Datensätze zur Verteilung an Endbenutzer. Sie erstellen eine App aus einem Arbeitsbereich, wählen die einzubindenden Inhalte aus und veröffentlichen sie. Benutzer installieren die App (oder erhalten einen Link per E-Mail) und sehen nur die freigegebenen Inhalte. Apps können auf bestimmte Zielgruppen (Zielgruppen) ausgerichtet sein, sodass verschiedene Teams unterschiedliche Inhalte in derselben App sehen. Apps erleichtern die gleichzeitige Freigabe von Berichtssammlungen für viele Personen => RLS-abhängig !!!

Beziehungen visualisieren: Die Komponenten stehen wie folgt in Beziehung: Datensätze (semantische Modelle) liefern Daten für Berichte . Berichte liefern visuelle Elemente , die Sie an Dashboards anheften können. Sie gruppieren verwandte Elemente in einem Arbeitsbereich und packen sie dann zur Verteilung in Apps .

Ein Power BI-Dashboard ist eine einzelne Seite (oft als Canvas bezeichnet), die mithilfe von Visualisierungen eine Geschichte erzählt. Da es auf eine Seite beschränkt ist, enthält ein gut gestaltetes Dashboard nur die wichtigsten Elemente dieser Geschichte. Die Visualisierungen im Dashboard werden als Kacheln bezeichnet. In den meisten Fällen gelangen Sie durch Auswahl einer Kachel zur Berichtsseite, auf der die Visualisierung erstellt wurde. learn.microsoft.com . Dies unterstreicht, dass es bei Dashboards um Erkenntnisse auf einen Blick geht, während es bei Berichten um detaillierte Untersuchungen geht.

Arbeitsbereiche und Arbeitsbereichsrollen

Arbeitsbereiche sind die kollaborativen Bereiche im Power BI-Dienst. Alle Inhalte (Datensätze, Berichte, Dashboards) befinden sich in einem Arbeitsbereich. Sie können mehrere Arbeitsbereiche für unterschiedliche Zwecke erstellen (z. B. „BI-Team-Arbeitsbereich“, „HR-Team-Arbeitsbereich“, „Finanzberichte“, „Marketinganalysen“ usw.).

Jeder Arbeitsbereich verfügt über eine Zugriffs- oder Mitgliederliste , in der Sie Personen (oder Azure AD-Gruppen) Rollen zuweisen. Die wichtigsten Rollen in einem Arbeitsbereich sind:

• Administrator: Volle Kontrolle. Administratoren können Benutzer hinzufügen oder entfernen, Rollen ändern, Arbeitsbereichseinstellungen aktualisieren, Apps veröffentlichen oder löschen und alle Funktionen nutzen, die Mitgliedern und Mitwirkenden zur Verfügung stehen. Administratoren können den Arbeitsbereich selbst auch löschen.

• Mitglied: Kann Inhalte (Berichte, Dashboards, Datasets) im Arbeitsbereich erstellen, bearbeiten und löschen. Mitglieder können die App des Arbeitsbereichs veröffentlichen oder aktualisieren. Sie können Elemente freigeben und Mitwirkende oder Betrachter hinzufügen.

• Mitwirkender: Kann Berichte und Dashboards im Arbeitsbereich erstellen, bearbeiten und löschen sowie Datenaktualisierungen planen. Mitwirkende können die App des Arbeitsbereichs jedoch nicht veröffentlichen oder neue Benutzer hinzufügen. Mit der entsprechenden Berechtigung eines Administrators können Mitwirkende die vorhandene App aktualisieren, jedoch keine App-Berechtigungen festlegen oder eine neue App erstellen.

• Betrachter: Nur Lesen. Betrachter können die Inhalte des Arbeitsbereichs sehen und mit ihnen interagieren (Dashboards und Berichte öffnen, Filter verwenden), aber keine Änderungen vornehmen oder Inhalte freigeben. Sie können keine Inhalte bearbeiten.

Eine hilfreiche Methode zur Erinnerung: Administrator > Mitglied > Mitwirkender > Betrachter in absteigender Reihenfolge der Berechtigungen. Alle außer dem Betrachter können Inhalte bearbeiten und verwalten, aber nur Administratoren und Mitglieder können die App-Veröffentlichung und Benutzerrollen verwalten.

Adding people to a Power BI workspace. Here the workspace owner is giving “Bianca Pisani” the Contributor role. Workspace roles (Admin, Member, Contributor, Viewer) control what each user can do in that workspace.

Sie weisen Rollen zu, indem Sie im Power BI-Dienst zum Arbeitsbereich gehen, auf das Zahnrad- oder Zugriffssymbol klicken und Benutzer oder Gruppen mit der gewünschten Rolle hinzufügen. Beachten Sie, dass die Sicherheit auf Zeilenebene (RLS) auch dann gilt, wenn jemand Mitglied oder Mitwirkender im Arbeitsbereich ist und Berichte oder Dashboards anzeigt (weitere Informationen zu RLS finden Sie weiter unten). Außerdem erfordern Arbeitsbereichsrollen (außer „Viewer“) Benutzer Pro-/PPU-Lizenzen.

Wichtige Unterschiede bei den Berechtigungen:

• Workspace-Administratoren können alles tun (Benutzer hinzufügen/entfernen, Workspace löschen, Apps veröffentlichen).

• Mitglieder können fast alles tun, außer den Arbeitsbereich zu löschen oder Rollen über ihrer Ebene zu ändern.

• Mitwirkende können Inhalte erstellen und ändern, jedoch keine App-Einstellungen oder Arbeitsbereichsmitglieder ändern.

• Zuschauer konsumieren Inhalte.

Diese Struktur gewährleistet eine sichere Zusammenarbeit: Designer (Mitglieder/Mitwirkende) erstellen und verfeinern Berichte, während Geschäftsbenutzer (Betrachter) nur den endgültigen Inhalt anzeigen können.

Sicherheit auf Zeilenebene (RLS): Daten sicher aufbewahren

Sicherheit und Zugriffskontrolle sind in jeder BI-Lösung von entscheidender Bedeutung. Eines der wichtigsten Tools in Power BI ist die Sicherheit auf Zeilenebene (RLS) , die die Datensichtbarkeit auf Zeilenebene (Datensatzebene) basierend auf dem Benutzer einschränkt. Stellen Sie sich RLS als Filter für das Datenmodell vor, der besagt: „Benutzer X kann nur Zeilen sehen, in denen Abteilung = Abteilung von X“ oder „Nur Transaktionen in meiner Region sehen“. RLS ist im Datenmodell (Desktop) definiert und wird im Dienst erzwungen, wenn Benutzer Berichte oder Dashboards anzeigen.

Sicherheit auf Zeilenebene ist in Szenarien wie den folgenden von entscheidender Bedeutung:

• Regionale Filterung: Vertriebsleiter sollten nur Daten für ihre Region sehen. Wenn John der Leiter der Region West ist, stellt RLS sicher, dass in Johns Berichten nur Daten für West angezeigt werden.

• Abteilungsbasierte Filterung: Der Manager jeder Abteilung sieht nur die Kennzahlen seiner Abteilung. Beispielsweise sieht die Personalabteilung nur die Personaldaten.

• Jede „As-Managed“-Ansicht: Alle Fälle, in denen vertrauliche Daten vor unbefugten Blicken verborgen werden sollten.

Power BI unterstützt zwei RLS-Stile:

• Statisches RLS: Sie erstellen feste Rollen in Power BI Desktop und definieren Filter (z. B. Abteilung = „Vertrieb“). Anschließend weisen Sie im Dienst jeder Rolle bestimmte Benutzer (oder Gruppen) zu. Beispielsweise filtert die Rolle „Vertrieb“ nach Abteilung = Vertrieb. Anschließend fügen Sie Alice der Vertriebsrolle, Bob der Marketingrolle usw. hinzu. Dies ist unkompliziert, aber bei vielen Benutzern/Rollen umständlich. Beispiel für statisches RLS:

[SalesPerson] = "Alice"

• Dynamisches RLS: Anstatt Filter fest zu codieren, verwenden Sie DAX-Funktionen wie USERNAME() oder USERPRINCIPALNAME() zusammen mit einer Mapping-Tabelle. Ihr Datenmodell könnte beispielsweise eine Tabelle mit Benutzern und deren Abteilungen enthalten. Sie erstellen eine Tabelle „Mitarbeiter“ mit den Spalten „Benutzername“ und „Abteilung“, verknüpfen sie mit der Hauptdatentabelle und setzen anschließend einen Filter wie „[Benutzername] = USERPRINCIPALNAME()“. Wenn Alice den Bericht öffnet, gibt USERPRINCIPALNAME() ihre E-Mail-Adresse zurück, und der Filter beschränkt die Daten automatisch auf ihre Abteilungszeilen. Dies lässt sich auf viele Benutzer skalieren, ohne dass für jeden einzelne eine eigene Rolle erstellt werden muss. Beispiel für dynamisches RLS:

[Employees] IN 

    CALCULATETABLE(

        VALUES(UserAccess[Department]),

        Employees[Username] = USERPRINCIPALNAME()

    )

RLS wird in Power BI Desktop unter „Modellierung > Rollen verwalten“ definiert, unabhängig davon, ob es sich um statische oder dynamische Rollen handelt. Sie erstellen eine oder mehrere Rollen, wählen eine Tabelle aus und legen einen Filter fest (entweder über ein Dropdown-Menü oder mit einem DAX-Ausdruck). Eine einfache statische Rolle könnte beispielsweise „FactTable[Region] = „West““ lauten. Ein dynamisches Beispiel wäre „[SalesRep] = USERPRINCIPALNAME()“.

Nachdem Sie die Rollen definiert haben, veröffentlichen Sie den Bericht (und seinen Datensatz) im Dienst. Anschließend öffnen Sie im Arbeitsbereich die Sicherheitseinstellungen des Datensatzes und fügen jeder Rolle Benutzer/Gruppen hinzu (für statisches RLS). Für dynamisches RLS filtert die DAX-Logik. Sie müssen jedoch weiterhin alle zu filternden Personen zuweisen (normalerweise fügen Sie dieser dynamischen Rolle breite Gruppen oder „Alle Mitarbeiter“ hinzu, da die Filterlogik die Datenmenge begrenzt).

Example of RLS: Defining an RLS role in Power BI Desktop. Here, the role “Example” applies a filter on the “Sales Territory” table. The DAX expression in the “Filter data” box might use dynamic logic (e.g., [Region] = USERPRINCIPALNAME()) to restrict data at runtime. This example shows a compound filter ([Region] = "West" || [Country] = "United States" && [Group] = "A") as an illustration of how filters look in the editor.

Wesentliche Nuancen: RLS gilt nur, wenn Inhalte mit der Rolle „Viewer“ (oder über Apps) genutzt werden. Administratoren, Mitglieder oder Mitwirkende im Arbeitsbereich umgehen RLS standardmäßig (sie können alle Daten sehen). Wenn Sie RLS testen, zeigen Sie den Bericht als „Testbenutzer“ mit Viewer-Zugriff an, um die korrekte Erfahrung zu simulieren.

Dynamisches RLS mit DAX

Für eine große oder wechselnde Benutzerbasis ist dynamisches RLS leistungsstark. Die Idee besteht darin, eine Benutzerzuordnungstabelle in Ihrem Modell zu führen. Beispielsweise enthält eine SalesReps-Tabelle Spalten wie „Benutzername“ (Benutzeranmeldename/UPN) und „Region“. Ordnen Sie SalesReps[Region] der Region Ihrer Primärdaten zu und definieren Sie anschließend eine Rolle mit DAX:

SalesReps[Username] = USERPRINCIPALNAME()

Wenn Alice ( alice@company.com ) den Bericht anzeigt, gibt USERPRINCIPALNAME() ihre E-Mail-Adresse zurück. Der Filter findet ihre Zeile in SalesReps, und sie sieht nur die Daten ihrer Region. Es ist keine separate Rolle für jede Person erforderlich.

Dynamische RLS-Schritte:

1. Fügen Sie eine Zuordnungstabelle hinzu , z. B. eine zweispaltige Tabelle (Benutzer, Abteilung). Diese kann manuell oder automatisch aus Ihrem HR-System eingegeben werden.

2. Beziehungen herstellen : Verknüpfen Sie diese Tabelle über den Abteilungs-/Regionsschlüssel mit Ihrer Faktentabelle.

3. Erstellen Sie eine Rolle auf dem Desktop : Verwenden Sie unter „Rollen verwalten“ den DAX-Editor und schreiben Sie Folgendes: [EmployeeName] = USERPRINCIPALNAME(). (Hinweis: Auf dem Desktop sieht USERNAME() wie Domäne\Benutzername aus; im Dienst entspricht es UPN. Verwenden Sie daher aus Gründen der Konsistenz am besten USERPRINCIPALNAME().)

4. Veröffentlichen und Benutzer zuweisen : Rufen Sie die Sicherheitseinstellungen des Datensatzes im Dienst auf. Fügen Sie alle relevanten Benutzer dieser Rolle hinzu. Da der DAX die eigentliche Filterung übernimmt, können Sie dieser Rolle eine breite Gruppe (z. B. „Alle Unternehmen“) zuweisen.

Der Blog von RADACAD zeigt beispielsweise ein Szenario, in dem eine Vertriebsmitarbeitertabelle eine Spalte „Benutzer“ (Anmeldung) enthält und jede Transaktion einen Vertriebsmitarbeiter hat. Die RLS-Rolle in Desktop war [Benutzer] = USERPRINCIPALNAME(), d. h. jeder Benutzer sieht nur seine Transaktionen. Ebenso können Sie nach Region filtern, indem Sie die Region des Benutzers in einer verknüpften Tabelle suchen.

datasturdy.com In der Praxis nutzen große Organisationen RLS häufig für Abteilungs- oder Regionalfilter: z. B. „Beschränken Sie den Zugriff, sodass Benutzer einer bestimmten Abteilung oder Region nur relevante Daten sehen. Beispielsweise greift die Vertriebsabteilung nur auf Vertriebsdaten zu; die Marketingabteilung auf Marketingdaten und Regionalmanager sehen nur die Daten ihrer Region.“

Beispiele für RLS-Szenarien

• Vertriebsregionen: Sie verfügen über eine Tabelle mit den Umsätzen nach Regionen. RLS stellt sicher, dass der Vertriebsleiter für Nordamerika nur die Zeilen für Nordamerika sieht. Sie können statische Rollen (Nordamerika, Europa, Asien) oder dynamische Rollen über eine Tabelle mit Benutzer-Region-Zuordnungen festlegen.

• Bürostandorte: Personaldaten des Unternehmens, wobei jeder Manager nur die Mitarbeiter im Büro sehen sollte. Der RLS-Filter könnte Mitarbeiter[Büro] = LOOKUPVALUE(Manager[Büro], Manager[Benutzername], USERPRINCIPALNAME()) sein.

• Direkte Berichte: In hierarchischen Situationen können Sie einem Manager Zugriff auf alle Daten seines Teams gewähren. Sie können dies mit einer Tabelle „Manager vs. Mitarbeiter“ und einem DAX wie Employee[Manager] = USERPRINCIPALNAME() oder Employee[Benutzername] = USERPRINCIPALNAME() implementieren.

Best Practice: Testen Sie RLS mit der Funktion „Als Rolle anzeigen“ auf dem Desktop oder der Funktion „Als Rolle testen“ im Dienst, um verschiedene Benutzer zu simulieren. Halten Sie Ihre Mapping-Tabellen stets mit aktuellen Benutzerinformationen auf dem neuesten Stand. Beachten Sie, dass RLS-Filter nur die Anzahl der Betrachter einschränken. Designer (mit Bearbeitungsrechten) umgehen diese Filter.

View as Role option in Modeling tab in Power BI Desktop

Dashboards vs. Berichte: Was ist der Unterschied?

Wenn Sie Power BI noch nicht kennen, können Dashboards und Berichte leicht verwechselt werden. Beide sehen ähnlich aus, dienen aber unterschiedlichen Zwecken:

• Berichte sind interaktive, mehrseitige Dokumente zur Entwurfszeit. Ein Bericht kann fünf Seiten umfassen: „Übersicht“, „Umsatz nach Region“, „Inventar“ usw. Sie erstellen Berichte in Power BI Desktop (oder bearbeiten sie im Service), indem Sie visuelle Elemente auf Seiten anordnen und Filter oder Slicer hinzufügen. Endbenutzer können in einem Bericht herumklicken, Drilldowns durchführen und Filter anwenden.

• Dashboards sind einseitige Sammlungen fixierter Visualisierungen . Stellen Sie sich vor, ein Berichtsautor fixiert einen wichtigen KPI oder ein Diagramm auf einem Dashboard. Ein gut gestaltetes Dashboard kann wichtige Umsatzzahlen, Gewinne, Trends usw. auf einer Seite darstellen. Es bietet eine Übersicht über die wichtigsten Kennzahlen. Dashboards können Visualisierungen aus verschiedenen Berichten und Datensätzen zusammenfassen. Dashboards werden häufig von Führungskräften genutzt, die nicht durch die Seiten blättern müssen, sondern die wichtigsten Zahlen im Blick behalten möchten.

Ein praktischer Vergleich: Berichte ähneln detaillierten Tabellen oder Präsentationen; Dashboards ähneln einer einseitigen Zusammenfassung oder dem Startbildschirm einer App. Klicken Sie im Service auf das Home-Symbol oder das Dashboard -Menü, um eine Liste der verfügbaren Dashboards anzuzeigen. Unter „Berichte“ werden Berichte angezeigt.

Wichtige Punkte:

• Ein Dashboard besteht immer aus einer Seite. Sie können nicht durch die Seiten eines Dashboards scrollen, sondern nur innerhalb der Visualisierungen.

• Ein Dashboard enthält Kacheln , die auf die Berichte verweisen. Durch Klicken auf eine Kachel gelangen Sie zum Bericht (oder einem Weblink).

• Sie können Warnmeldungen auf Dashboard-Kacheln festlegen (z. B. „Senden Sie mir eine E-Mail, wenn der Umsatz 100.000 $ übersteigt“), in Berichten ist dies jedoch nicht möglich.

• Dashboards können Daten aus mehreren Quellen kombinieren. Berichte beschränken sich auf einen Datensatz pro Seite.

• Oft entwerfen Sie zuerst einen Bericht und heften dann die wichtigen visuellen Elemente an ein Dashboard an.

Erstellen und Verwalten von Power BI-Apps

Power BI -Apps bieten eine moderne Möglichkeit, Inhalte zu bündeln und an Endbenutzer zu verteilen. Stellen Sie sich eine App als übersichtlich organisiertes Paket aus Berichten, Dashboards und Datensätzen vor, das Sie mit einem Team oder dem gesamten Unternehmen teilen. Mit Apps können Sie ganz einfach Updates bereitstellen und steuern, wer was sieht.

Warum Apps verwenden? Apps eignen sich ideal, um fertige Inhalte mit Geschäftsbenutzern zu teilen, die keinen Zugriff auf den Arbeitsbereich haben sollten. Anstatt jedem Zugriff auf den Arbeitsbereich zu gewähren, stellen Sie ihnen eine App zur Verfügung. Benutzer finden veröffentlichte Apps im Power BI-Dienst (Apps-Menü oder Store) oder können ihnen einen Link per E-Mail senden. Apps können auch automatisch über die Administratoreinstellungen installiert werden.

App erstellen: Nur Workspace-Administratoren und -Mitglieder können Apps erstellen oder aktualisieren. Der Ablauf ist im Allgemeinen wie folgt:

1. Wählen Sie einen Arbeitsbereich aus , in dem Ihre überarbeiteten Inhalte gespeichert sind. (Hier stellen Sie normalerweise die Berichte fertig.)

2. Klicken Sie im Arbeitsbereich auf „App veröffentlichen“ (oder „App aktualisieren“, falls vorhanden).

3. Auf dem Einrichtungsbildschirm der App finden Sie Schritte wie:

   • Einrichtung: Benennen Sie die App, beschreiben Sie sie und fügen Sie optional ein Logo hinzu. Wählen Sie aus, wer Zugriff haben soll (alle in der Organisation oder bestimmte Benutzer/Gruppen).

   • Navigation: (Bei mehreren Seiten in Berichten oder Dashboards können Sie den Navigationsbereich anordnen.)

   • Inhalt: Wählen Sie aus, welche Elemente aus dem Arbeitsbereich einbezogen werden sollen. Wenn Sie möchten, dass fortgeschrittene Benutzer ihre Berichte erstellen, können Sie Dashboards, Berichte und die zugrunde liegenden Datensätze einbeziehen.

   • Zielgruppe: Mit der neuen App-Erfahrung können Sie mehrere Zielgruppen konfigurieren (mehr dazu weiter unten).

4. Überprüfen und veröffentlichen . Anschließend können die App-URL und die Installationsanweisungen freigegeben werden.

Nach der Veröffentlichung sehen App-Benutzer anstelle des reinen Arbeitsbereichs eine benutzerfreundliche Oberfläche. Sie können in der App nichts bearbeiten; sie können lediglich mit den Berichten interagieren (Filter, Kreuzfilter, Drillthrough usw.).

How to create an App in Power BI Service

Adding content (Reports, Dashboards) in the App to be shown

The Power BI App builder’s Audience tab. Here, the creator can click “New Audience” and hide or show different items for each audience. For example, the “Supplier Quality” dashboard is visible to Audience1, while “IT Spend Analysis” is only visible to the new audience.

Mehrere Zielgruppen: Apps auf Teams zuschneiden

Eine der besten Funktionen von Power BI-Apps ist die Funktion für mehrere Zielgruppen . Das bedeutet, dass dieselbe App verschiedenen Benutzergruppen unterschiedliche Inhalte anzeigen kann. Beispielsweise können Vertrieb und Marketing dieselbe App verwenden, aber Sie können vertrauliche Marketingdaten vor dem Vertriebsteam nach Zielgruppe verbergen.

So funktioniert es:

• Im App-Erstellungsablauf gibt es die Registerkarte „ Zielgruppe “. Alle enthaltenen Inhalte sind standardmäßig für alle sichtbar, die auf die App zugreifen können. Sie können jedoch auf „Neue Zielgruppe“ klicken, um eine Untergruppe zu definieren.

• Jede Zielgruppe ist lediglich eine Bezeichnung (z. B. „Vertriebsteam“, „Finanzmanager“). Unter jeder Zielgruppe verwenden Sie ein Augensymbol, um bestimmte Dashboards, Berichte oder sogar Seiten für diese Gruppe ein- oder auszublenden .

• Nachdem Sie Inhalte pro Zielgruppe ausgewählt haben, navigieren Sie zu „ Zielgruppenzugriff verwalten“ und wählen aus, welche Benutzer oder Azure AD-Gruppen zu jeder Zielgruppe gehören . Sie können eine Zielgruppe auf „Gesamte Organisation“ (jeder) festlegen oder auf bestimmte Benutzer beschränken.

• Es gibt auch erweiterte Schalter pro Zielgruppe, wie „Personen das Teilen von Datensätzen in dieser App erlauben“ oder „Erstellen von Inhalten erlauben“ (wodurch fortgeschrittene Benutzer ihre Berichte basierend auf enthaltenen Datensätzen erstellen können).

Praktisches Beispiel: Sie haben eine App mit einer Reihe von Finanzberichten. Sie erstellen Zielgruppe A für Führungskräfte, die alles sehen (Gewinn- und Verlustrechnung, Bilanz, Ausgaben), und Zielgruppe B für Abteilungsleiter, die nur die für ihre Abteilung relevanten Kennzahlen sehen. Im Reiter „Zielgruppe“ verbergen Sie detaillierte Drillthrough-Berichte vor Zielgruppe B und geben nur Dashboards auf hoher Ebene frei.

Wichtige Fallstricke:

• Versteckte Inhalte sind weiterhin zugänglich, wenn Sie direkte Links angeben (es sei denn, Sie deaktivieren „Zugriff auf versteckte Inhalte erlauben“). Anders ausgedrückt: „Ausblenden“ entfernt die Inhalte aus dem Menü und der Navigationsleiste, aber ein versierter Benutzer kann einen Bericht trotzdem per URL öffnen. Verwenden Sie Sicherheitsfunktionen (Rollen), wenn es sich um wirklich sensible Inhalte handelt, oder entfernen Sie sie vollständig aus der App.

• Dashboards mit ausgeblendeten Berichten: Wenn eine Dashboard-Kachel auf einen Bericht verweist, den Sie vor einer Zielgruppe verbergen, wird bei dieser Kachel ein Fehler ausgegeben („Bericht existiert nicht oder keine Berechtigung“). Stellen Sie sicher, dass Sie den Bericht einbinden und anzeigen oder die Kachel entfernen.

• Build-Berechtigungen: Aktivieren Sie „Build zulassen“ nur, wenn die Zielgruppe eigene Analysen erstellen darf. Standardmäßig können App-Nutzer nur anzeigen, nicht bearbeiten.

App Audience access settings. Here, you specify who is in each audience and advanced options (like “allow build content”). In this example, the “Product” audience can be set to everyone in the org or specific users and can be allowed to share or build with the app’s datasets.

Das Konfigurieren mehrerer Zielgruppen erfordert zwar etwas Planung, bietet aber eine hervorragende Möglichkeit, eine App wiederzuverwenden. So wird sichergestellt, dass Benutzer nur das sehen, was für sie bestimmt ist, ohne separate Arbeitsbereiche oder Apps verwalten zu müssen.

Schritt für Schritt: Eine Power BI-App veröffentlichen 🪄

Hier ist eine kurze Anleitung zum Veröffentlichen einer App (mithilfe der neuen Erfahrung):

1. Bereiten Sie Ihren Arbeitsbereich vor: Stellen Sie sicher, dass alle Berichte, Dashboards und Datensätze getestet und aktuell sind. Entscheiden Sie, was in die App gehört.

2. Klicken Sie auf „App veröffentlichen“: Klicken Sie in Ihrem Arbeitsbereich (oben rechts) auf App aktualisieren (falls vorhanden) oder App veröffentlichen .

3. App-Details einrichten: Sie können Ihrer App optional einen Namen, eine Beschreibung und ein Logo oder eine Designfarbe geben. Legen Sie fest, ob die App für Ihre gesamte Organisation oder nur für bestimmte Gruppen verfügbar sein soll. (Sie können beispielsweise Azure AD- oder O365-Gruppen hinzufügen.)

4. Inhalte auswählen: Wählen Sie auf der Registerkarte „Inhalte“ aus, welche Dashboards, Berichte und Datensätze in die App aufgenommen werden sollen. Hier können Sie auch die Navigationsstruktur anpassen (z. B. ein benutzerdefiniertes Menü).

5. Zielgruppen konfigurieren: Wie bereits erwähnt, können Sie auf der Registerkarte „Zielgruppe“ mehrere Zielgruppen erstellen und Elemente entsprechend ein- oder ausblenden. Klicken Sie anschließend auf „Zielgruppenzugriff verwalten“ , um jeder Zielgruppe Benutzer/Gruppen zuzuweisen.

6. Überprüfen und veröffentlichen: Der Builder zeigt eine Vorschau der App-Navigation an. Stellen Sie sicher, dass alles korrekt aussieht. Klicken Sie anschließend auf „Veröffentlichen“ (oder „Aktualisieren“ ). Sie erhalten einen Link, den Sie teilen können.

7. Benutzer installieren die App: Geschäftsbenutzer können im Power BI-Dienst im Abschnitt „Apps“ nach Ihrer App suchen. Sie wird in einigen Mandanten ohne „Jeder“-Zugriff automatisch angezeigt. Andernfalls senden Sie ihnen den Link oder die E-Mail.

Nach der Veröffentlichung werden alle Aktualisierungen, die Sie im Arbeitsbereich vornehmen (z. B. ein neuer Bericht, Datenänderungen oder die Behebung eines Fehlers), erst nach der erneuten Veröffentlichung der App angezeigt. Es handelt sich jedes Mal um eine neue Version; App-Benutzer sehen den aktualisierten Inhalt, ohne dass ihre Links oder Lesezeichen beschädigt werden.

Fehlerbehebung und bewährte Methoden 💡

Wie bei jedem komplexen System können neue Power BI-Dienstbenutzer einige häufige Probleme haben. Hier sind einige Tipps:

• „Ich kann die Daten nicht sehen – alles ist leer!“ Das liegt in der Regel an RLS oder Berechtigungen. Überprüfen Sie, ob das Benutzerkonto in der richtigen RLS-Rolle im Datensatz enthalten ist und ob der Benutzer mindestens Viewer-Zugriff auf den Arbeitsbereich oder die App hat. Denken Sie daran: Arbeitsbereichs-Mitwirkende sehen standardmäßig alle Daten.

• „Dashboard-Kachel meldet, dass Bericht nicht existiert.“ Wenn eine Dashboard-Kachel auf einen Bericht verweist, der nicht in der App für diese Zielgruppe enthalten ist (oder der Bericht ausgeblendet ist), tritt dieser Fehler auf. Beheben Sie das Problem, indem Sie den Bericht in die App einbinden und sichtbar machen oder die Kachel entfernen.

• „Ich habe das Dashboard freigegeben, aber niemand hat es verstanden.“ Die Dashboardfreigabe im Power BI-Dienst funktioniert anders als die Freigabe einer Datei. Wenn Sie ein Dashboard freigeben, müssen Sie sicherstellen, dass die Berichtsbesitzer den Zugriff auf das zugrunde liegende Dataset freigeben oder Apps verwenden. Oft ist es einfacher, eine App freizugeben: Fügen Sie der App oder Zielgruppe Benutzer hinzu, anstatt die Dashboardfreigabe zu verwenden.

• Lizenzprobleme: Einige Funktionen (wie die Freigabe außerhalb Ihrer Organisation, größerer Speicherplatz oder die Befreiung von der Pro-Lizenz) erfordern Premium-Kapazität oder die entsprechenden Pro-Lizenzen. Wenn jemand Inhalte nicht anzeigen kann, prüfen Sie, ob der Arbeitsbereich Premium ist und ob eine Pro-Lizenz erforderlich ist.

• Datenaktualisierung schlägt fehl: Ein veröffentlichter Bericht zeigt möglicherweise keine neuen Daten an, wenn die geplante Aktualisierung nicht ausgeführt wurde oder das Gateway falsch konfiguriert ist. Überprüfen Sie den Aktualisierungsverlauf des Datasets und den Gateway-Status in den Einstellungen des Arbeitsbereichs.

• App wird nicht aktualisiert: Denken Sie daran, nach Änderungen die App zu aktualisieren. Die App wird nicht automatisch aktualisiert. Leeren Sie außerdem den Browser-Cache oder bitten Sie die Benutzer, die App-Liste zu aktualisieren, wenn die neue Version nicht angezeigt wird.

• Mehrere Zielgruppen, denen Inhalte fehlen: Seien Sie vorsichtig mit Abhängigkeiten. Wenn Zielgruppe A Bericht X sieht, Zielgruppe B jedoch Dashboard Y mit Kacheln aus Bericht X (das für B ausgeblendet ist), wird die Ansicht von B unterbrochen. Der App-Builder warnt davor. Überprüfen Sie immer, ob jede Zielgruppe die Berichte hinter ihren Dashboards hat, oder aktivieren Sie gegebenenfalls die Option „Zugriff auf ausgeblendete Inhalte zulassen“.

• Verschachtelte Arbeitsbereiche oder arbeitsbereichsübergreifende Daten: Wenn Ihre App Daten aus anderen Arbeitsbereichen bezieht, stellen Sie sicher, dass alle Betrachter auch auf diese Datensätze zugreifen können. Ein Datensatz kann RLS nur innerhalb seines Arbeitsbereichskontexts erzwingen.

Example of error within Power BI Service

Best Practice-Tipps:

• Halten Sie den Arbeitsbereich aufgeräumt: Platzieren Sie nur überarbeitete, freigegebene Inhalte in einem App-Arbeitsbereich. Verwenden Sie separate Entwicklungsarbeitsbereiche für Rohentwürfe.

• Rollen dokumentieren: Notieren Sie, wer welche Arbeitsbereichsrolle hat, um Verwirrung zu vermeiden. Azure AD-Gruppen erleichtern die Verwaltung.

• Testen Sie alles: Verwenden Sie die Option „Als Rolle anzeigen“ auf dem Desktop und die Zielgruppenvorschau in Apps, um sicherzustellen, dass die Benutzer das sehen, was sie sehen sollen.

• Benennung und Beschreibung: Geben Sie Ihren Berichten/Dashboards vor der App-Erstellung eindeutige Titel. Nutzern wird ein Menü mit diesen Namen angezeigt. Ein kurzer Erklärungstext in der App-Beschreibung ist ebenfalls hilfreich.

• Nutzung überwachen: Rufen Sie im Dienst den Arbeitsbereich auf und überprüfen Sie die Nutzungsmetriken, um zu sehen, wer welchen Bericht anzeigt. Dies kann zur Verbesserung der App beitragen.

Wenn Sie diese Bausteine – Arbeitsbereiche, Rollen, RLS, Apps und Zielgruppen – verstehen, können Sie ein sicheres, organisiertes und benutzerfreundliches Power BI-Service-Setup entwickeln. Power BI Service ist ein leistungsstarker Hub, um Ihre Analysen in zugängliche, rollenbasierte Erkenntnisse für alle im Unternehmen umzuwandeln.

Quellen: Einige Konzepte und Best Practices, zusammengefasst aus der Microsoft Power BI-Dokumentation (learn.microsoft.comlearn.microsoft.comlearn.microsoft.com ), den Expertenblogs (datasturdy.comradacad.com) und praktischen Erfahrungen mit Power BI. Jeder gezeigte Screenshot stammt von offiziellen Power BI-Oberflächen und meiner Testumgebung.