How I like to present this information

I think the information when the data model was last updated is probably the most important. I like to place this information directly on the report so that it is immediately visible and, in case the report is printed, it is also included on the print (…yes, many customers want to be able to print their reports 😐 ). Since this information is only needed in the second place and takes up more space in case of a data model with several fact tables, I provide this information via a visual header tooltip. This tooltip can be called up when this information is needed and thus does not constantly take up space on the report. Here I provide three pieces of information:

1. The name of the table +
2. the date column, on the basis of which I determine the max date and
3. the actual maximum date

The animated GIF below shows how I provide this information:

If you are now wondering how this information gets into the report, read on.

Latest data model refresh

There are several approaches to store and report the lastest update of the data model. I present 3 versions and all those versions are based on a Power Query query, which provides the interesting timestamp , which is then loaded into the data model as a disconnected and invisible single-column, single-row  table.

Version #1: DateTime.LocalNow()

You can find several solutions for this topic which use the M-function DateTime.LocalNow() to load a table which stores the current time at every refresh of the data model. I blogged about it in 2017 (in German) and here you can find a similar version from Kasper de Jonge. The problem with this approach is the following: The datetime value returned by DateTime.LocalNow() depends on the system of the computer on which the M script is executed. Which computer this is is sometimes not clear at first sight. Here are a few scenarios as an example:

You publish manually from Power BI Desktop to the Power BI service

DateTime.LocalNow() returns the datetime value of the operating system on which Power BI Desktop runs.

Scheduled refresh based on cloud data sources (no Gateway involved)

In case you are working with cloud data sources, the M-script is executed on the server in the Microsoft data center, where your Power BI datasets are located. In my case this is a data center in Ireland. Ireland is not in the same time zone as Germany. Therefore DateTime.LocalNow() returns a different value here than e.g. on my local laptop.

Scheduled refresh based on on-premises data sources (Gateway involved)

If you automate the data update to the Power BI service through an on-premises data gateway, all M-scripts are executed in the gateway before they pass through the network in compressed form to the Power BI service. Thus, the datetime value returned in this case depends on the system on which the gateway is installed.

There are certainly other scenarios. What these 3 points should show is that DateTime.LocalNow() is probably not the safest method to get the desired result. Let’s look at alternatives.

Version #2: DateTimeZone.FixedUtcNow() to the rescue

An alternative approach would be to use the function DateTimeZone.FixedUtcNow() in combination with DateTimeZone.SwitchZone() like so: DateTimeZone.SwitchZone( DateTimeZone.FixedUtcNow(), 1). While DateTimeZone.FixedUtcNow() displays the current time in ‚Coordinated Universal Time‘, the second parameter of the DateTimeZone.SwitchZone() function lets me shift the UTC time by x hours (and also minutes if needed). This sounds like a great alternative to DateTime.LocalNow() but the devil is in the details.

Since I live in Germany and we are still jumping diligently between summer time (aka Daylight savings time) and winter time here, in my case this difference to UTC time cannot be static, but has to move between 1 and 2 depending on the date. I have already blogged about this here in German.

So this approach leads definetely to a useful result, but instead of calculating the – sometimes changing – difference to UTC time, it would be nicer if you could simply specify the desired time zone and get the datetime value, wouldn’t it? In this case I use REST API calls.

Version #3: Calling a REST API

Instead of worrying about how to calculate the difference between UTC and my own time zone, you could use a web service of your choice. The following script calls a REST API that returns the current date and time in the desired time zone (passed as parameter), which in my case is CET – Central European Time.

Whichever of the above methods you choose to save the time of the lastest data update: The result will be a single-column and single-row disconnected table in the data model, which you will probably hide there.

Putting this info on the report

To put this info into a report, you should put the datetime value into a DAX-measure, so that you can control the formatting (including line breaks). The following DAX statement does the job:

LastRefresh =
„Latest model refresh: „ & UNICHAR ( 10 )
    & FORMAT ( VALUES ( ‚LatestRefresh'[timestamp] ), „dd/mm/yyyy hh:mm:ss“ )

UNICHAR(10) creates the line break and the FORMAT() function makes sure I can format the datetime value as I need it. Put this measure in a card visual and you’re good to go. Now I make sure that the transaction data in the fact tables is up to date.

Last record of the transaction tables (aka fact table)

In case the data sources doesn’t already provide the data in the necessary structure, I am a strong advocate of doing all ETL tasks in Power Query, even if DAX could partially do the same tasks. Therefore, there are almost never columns or tables calculated with DAX in my data models. In the current case, this is different. My data model has 3 fact tables. In order to know if my data sources contain current data, I select the corresponding date columns from the fact tables, which I want to check for actuality. Normally these are date columns which are related to the calendar table. Doing this in Power Query could take muuuuch longer than doing it with DAX, so the decision is easy.

To create a table using DAX, which gives me the necessary information, I use the following DAX statement:

MaxDatesFactTables =
{
     ( „PnL_ACT (column: ‚Investment date‘ )“, CALCULATE ( MAX ( PnL_ACT[Invest date] ), ALL ( PnL_ACT ) ), 3 ),
     ( „PnL_PLAN (column: ‚date‘)“, CALCULATE ( MAX ( PnL_PLAN[date] ), ALL ( PnL_PLAN ) ), 2 ),
     ( „PnL_Forecast (column: ‚date‘)“, CALCULATE ( MAX ( PnL_FC[date] ), ALL ( PnL_FC ) ), 1 )
}

The result looks as follows:

The three columns contain the following information:

• Value1: Name of the fact table + info, based on which column the actuality of the data was determined.
• Value2: The maximum date of this specific column
• Value3: Using this value I can sort the table in the report.

Now let’s take a look at how I prefer to present this info.

This is how I prefer to present this information

I think the info, when the dataset had it’s latest refresh is important almost everytime… that’s why I include it on every page… but what about the latest dates in each fact table? This can be important, but I hardly need this info every single time I take a look at a report page… This is where visual specific tool tips become handy… I create a tooltip page (see the official documentation to know how that works) on which I display the disconnected table „MaxDatesFactTables “ as a matrix. Since the table created in DAX has the headings value1, value2 and value3, I overwrite them in the column captions of the matrix visual: value1 becomes Table and value2 becomes Max Date.

To place this tooltip in the visual header of the card visual, I go to the format properties of the card visual in which the LatestRefresh is located.

I turn on the visual header (if not already done) and activate the ‚Visual header tooltip icon‘. After that a new menu item appears in the format properties: ‚Visual header tooltip‘. Here I select my tooltip page in the field ‚report page‘. Done! 🙂

Additional information in the Power BI service: When was last uploaded?

In addition to the lastest refresh of the data model and the actuality of the data in the data source, the question sometimes arises as to when the data was last uploaded to the Power BI service. If you update your data via scheduled refresh, the time of the last model refresh and upload to the Power BI service will be (nearly) identical. However, if you manually publish your data to the Power BI service (via Power BI Desktop), then model refresh and publishing to the Power BI service are two processes that can vary greatly in time. This information is available to every user directly in the report.

And as mentioned at the beginning: Even if you automatically update your Power BI dataset (and thus the lastest model refresh and the upload to the Power BI service have identical times): If you want to print the report, you have to put the info on the report yourself 😉

Cheers from Germany,

Lars

Lars Schreiber

Lars ist Berater, Entwickler und Trainer für Microsoft Power BI. Er ist zertifizierter Power BI-Experte und Microsoft Trainer. Für sein Engagement in der internationalen Community wurde Lars seit 2017 jährlich durch Microsoft der MVP-Award verliehen. Lies hier mehr…

ssbi-blog.de

Der Beitrag Let your users know how up-to-date their data is erschien zuerst auf THE SELF-SERVICE-BI BLOG.

Links

LinkedIn-Profil Ula Jessen

LinkedIn-Profil Lucas Schroth

process.science GmbH & Co. KG

Process Mining Showcases

Transkipt

Folgt…

Lars Schreiber

Lars ist Berater, Entwickler und Trainer für Microsoft Power BI. Er ist zertifizierter Power BI-Experte und Microsoft Trainer. Für sein Engagement in der internationalen Community wurde Lars seit 2017 jährlich durch Microsoft der MVP-Award verliehen. Lies hier mehr…

ssbi-blog.de

Der Beitrag Ula Jessen und Lucas Schroth über Process Mining mit Power BI (German) erschien zuerst auf THE SELF-SERVICE-BI BLOG.

Links

Hier kannst Du Melissas Diagramm (und andere coole Helferlein) herunterladen.

Ich werde häufiger nach Büchern zum Thema Power BI gefragt. Das einzige (gute) Buch, das ich kenne, das die Power BI-Plattform als Ganzes betrachtet, ist das jährlich neu erscheinende Buch „Applied Power BI“ von Teo Lachev. Ich kaufe es jedes Jahr und bin von dessen Qualität wirklich überzeugt.

Transkipt

Folgt bald…

Lars Schreiber

Lars ist Berater, Entwickler und Trainer für Microsoft Power BI. Er ist zertifizierter Power BI-Experte und Microsoft Trainer. Für sein Engagement in der internationalen Community wurde Lars seit 2017 jährlich durch Microsoft der MVP-Award verliehen. Lies hier mehr…

ssbi-blog.de

Der Beitrag Podcast – Überblick über die Power BI-Plattform erschien zuerst auf THE SELF-SERVICE-BI BLOG.

Als Abonnent meines Newsletters erhältst Du die Beispieldateien zu den Beiträgen dazu. Hier geht’s zum Abonnement des Newsletters!

Allgemeine Begriffsklärung

Arbeitsbereiche (engl. Workspace) existieren im Power BI service. Ganz allgemein kannst Du sie Dir als Container vorstellen, in welchen sog. Power BI-Artefakte abgelegt werden können, also u. a. Berichte, Datasets und Dashboards. Kollegen können dann an bestimmten Artefakten zusammenarbeiten. Ich werde im weiteren Beitrag den englischen Begriff Workspace verwenden, weil Du beim Nutzen einer Suchmaschine hierzu deutlich mehr sinnvolle Treffer erhalten wirst, als zu Arbeitsbereichen.

Es gibt zwei unterschiedliche Formen von Workspaces, die für unterschiedliche Zwecke gedacht sind und auch unterschiedliche Eigenschaften haben. Darauf gehe ich jetzt im Detail ein…

Unterschiedliche Formen von Workspaces

Workspaces existieren ausschließlich im Power BI service, nicht in Power BI Desktop, oder im Power BI Report Server. Doch Workspace ist nicht gleich Workspace: es gibt verschiedene Formen.

Schauen wir uns die beiden Workspace-Formen mal im Detail an.

My Workspace (Mein Arbeitsplatz)

Diese Form des Workspaces ist so etwas wie der „Desktop“ auf Deinem PC. Es gibt also genau einen Workspace dieser Art pro Nutzer. Auf hier gespeicherte Power BI-Artefakte kannst ausschließlich Du selbst zugreifen. Auf diesen Bereich hat niemand Zugriff, außer Dir.

Zweck

Der Zweck des My Workspace besteht darin, Berichte zu Testzwecken hochzuladen, oder darin jene Power BI-Artefakte zu speichern, die niemandem außer Dir selbst zur Verfügung stehen sollen. Du kannst zwar Artefakte aus diesem Workspace heraus teilen (über sog. spontanes Teilen: Wie das geht, beschreibe ich im Detail in dieser Reihe), aber Du kannst keinen Deiner Kollegen dazu einladen, innerhalb Deines My Workspaces gemeinsam an Inhalten zu arbeiten. Sofern Du Dir also nicht 100%ig sicher bist, dass der hochzuladende Inhalte (auch zukünftig) ausschließlich von Dir selbst genutzt wird, vermeide bitte den Upload in diese Form des Workspaces.

Rechte

Im My Workspace gibt es keine Rollen oder Rechte. Es ist Dein Workspace und Du kannst hier machen was Du möchtest. Du bist quasi der Administrator dieses Workspace, kannst diesen jedoch nicht löschen. Die einzige Einstellung die Du für die Administration des My Workspace vornehmen kannst, ist ihn auf eine dedizierte Kapazität umzuschalten, sofern Deinem Unternehmen Power BI Premium zur Verfügung steht.

Lizenz

Jede Power BI-Lizenz besitzt einen My Workspace – auch die kostenlose Free-Lizenz.

Workspace (ehemaliger App-Workspace)

Diese Form des Workspaces wurde bis vor kurzem noch als „App„-Workspace bezeichnet. Diese Namensgebung stammt daher, dass App-Workspaces ihre Inhalte über eine sog. App an die Konsumenten freigeben. Mittlerweile hat Microsoft sich jedoch gegen diese Bezeichnung entschieden und ist zurückgegangen auf den Begriff Workspace. Im Gegensatz zum My Workspace kann es hiervon pro Nutzer gegenwärtig bis zu 1.000 verschiedene Workspaces geben. Workspaces können in eine sog. „klassische“ Version (V1) und eine neue Version (V2) unterschieden werden. Während die klassische Version auf O365-Gruppen basierte, ist die neue Version davon entkoppelt. Auf die Details zwischen diesen beiden Versionen gehe ich in diesem Beitrag nicht weiter ein. Was Du wissen solltest ist, dass die V1-Version in Zukunft durch die V2 ersetzt werden wird. Somit ist es ratsam, weitere Workspaces gleich als V2 anzulegen. Dies ist mittlerweile auch die Default-Einstellung beim Anlegen eines Workspaces. Ich gehe im weiteren Beitrag ausschließlich auf V2-Workspaces ein, sofern ich nicht explizit etwas anderes erwähne.

Zweck

Der Zweck der Workspaces, ist das gemeinsame Arbeiten verschiedener Kollegen an Reports, paginierten Reports und Dashboards. Kollegen können für einen solchen Workspace berechtigt und mit einer von vier unterschiedlichen Rolle versehen werden, die Ihnen unterschiedliche Rechte innerhalb des Workspace geben. Sobald ein Datenmodell/ Dataset in Power BI Desktop erstellt und in den Power BI service hochgeladen wurde, kann dies als Basis für die gemeinsame Erstellung von Report, paginierten Reports und Dashboards im Workspace dienen. Eine Möglichkeit, gemeinsam Datenmodelle innerhalb eines Workspaces zu erstellen, d. h. Modellierung von Tabellen, das Definieren von Beziehungen und das Schreiben von DAX-Measures, ist gegenwärtig im Power BI service nicht möglich.

Neben dem Zweck der gemeinsamen Erstellung von Inhalten, können in einem Workspace auch Excel-Arbeitsmappen gespeichert und für die Verteilung an die Konsumenten (via App) vorgesehen werden.

Im Unterschied zum My Workspace ist es in (V2-)Workspaces möglich, Dataflows zu erstellen und zu nutzen. Hierbei handelt es sich um wiederverwendbare M-Skripte (wie man sie aus Power Query kennt), deren Ergebnisse in einem Azure Datalake Storage Generation 2 (kurz ADLS G. 2) gespeichert werden. Zu diesem Thema kann ich Dir zwei Artikel meines Kollegen Hans Peter Pfister sehr ans Herz legen (Artikel 1 und Artikel 2).

Das schlussendliche Ziel eines Workspaces, ist in der Regel die Veröffentlichung der (teilweise gemeinsam) erstellten Inhalte an die Konsumenten via App. Hierbei kann pro Inhalt (Report, Excel-Datei, etc.) separat definiert werden, ob dieser in der aktuell veröffentlichten App beinhaltet sein soll, oder noch ausschließlich zur Weiterentwicklung im Workspace zur Verfügung steht. Wie dies geht zeigt der folgende Screenshot:

Hierüber findet eine Trennung zwischen Entwicklungsumgebung (Workspace) und Produktivumgebung (App) statt, die sehr nützlich ist. Es ist wichtig hierbei im Hinterkopf zu behalten, dass es ist nicht möglich, aus einem Workspace heraus mehr als eine App zu veröffentlichen. Das Verhältnis Workspace zu App ist immer 1:1!

Rechte

Die Rechte innerhalb des Workspace sind rollenabhängig. Ich gehe darauf weiter unten unter „Rollen innerhalb eines Workspaces“ ein.

Lizenzen

Auch die Power BI-Lizenzen für die Mitglieder eines Workspaces sind rollenabhängig. Hier kannst Du jedoch pauschal sagen, dass jedes Mitglied eine Pro-Lizenz von Power BI benötigt. Sofern der Workspace jedoch auf der Premium-Kapazität liegt, können Kollegen mit der Viewer-Rolle auch mit der Free-Lizenz auf den Workspace zugreifen.  Weil es vielleicht nicht ganz eindeutig ist: Auch für das Anlegen eines Workspaces benötigst Du eine Pro-Lizenz, weil Du beim Erstellen eines Workspaces automatisch zu dessen Administrator wirst.

Voraussetzungen für das Anlegen von Workspaces

Um einen Workspace anlegen zu können müssen zwei Voraussetzungen erfüllt sein:

1. Du musst über eine Power BI-Pro-Lizenz verfügen (hier liest Du, wie Du herausbekommst, welche Lizenz du hast)
2. Im Verwaltungsportal von Power BI muss durch den Power BI-Admin das Anlegen von Workspaces für Dich erlaubt sein.

Der folgende Screenshot zeigt, wie im Power BI-Verwaltungsportal durch den Power BI-Admin definiert werde kann, wer Workspaces anlegen darf:

Ist die zweite Voraussetzung nicht erfüllt, erhältst Du folgende Fehlermeldung:

Wenn alle Voraussetzungen erfüllt sind, kannst Du die gewünschten Workspaces selbst erstellen.

So legst Du einen neuen Workspace an

Einen Workspace im Power BI service zu erstellen, ist recht simpel, wie der folgende Screenshot in zwei Schritten zeigt:

Im Anschluss daran kann der zu erstellende Workspace mit

1. einem Bild,
2. einem (möglichst sprechenden) Namen und
3. einer Beschreibung versehen werden:

In einer großen Organisation kann es schnell zu mehreren hundert Workspaces kommen. Damit Du hier nicht der Überblick verlierst, bzw. sich noch jemand zurecht finden kann, solltest Du Dir Gedanken machen, nach welcher Logik Ihr Eure Workspaces benennt und vor allem auch erstellt…

Organisation von Workspaces

Vor dem Anlegen von Workspaces ergeben sich verschiedene Fragen:

1. Mit welcher Logik lege ich Workspaces an – z. B. einen je Abteilung, oder einen je Projekt?
2. Welche Systematik sollte ich für die Namensvergabe wählen – sind z. B. Präfixe vor den Workspace-Namen sinnvoll?
3. Passen all meine Inhalte in einen Workspace?

Logik der Workspace-Erstellung

Hier ist Deiner Kreativität natürlich keine Grenze gesetzt. Allerdings solltest Du Dir in Erinnerung rufen, dass es für jeden Workspace exakt eine App gibt, die aus dem Workspace heraus veröffentlicht werden kann. Das bedeutet, dass ALLE Power BI-Artefakte innerhalb eines Workspace beim Update einer App entweder in der App enthalten sind, oder eben nicht. Ich kann hier keine Unterscheidungen machen, dass einige Empfänger nur die zwei Exceldateien und das eine Dashboard und andere Empfänger alles bekommen. Dieser Umstand allein macht es vermutlich notwendig, mehr als einen Workspace pro Abteilung ( z. B. Controlling) zu haben. Wahrscheinlich ist es realistischer innerhalb einer Abteilung einen Workspace pro (Berichts-)Projekt zu haben: z. B. „monatlicher Umsatzreport – Vorstand“, „monatlicher Umsatzreport – Analysten“.

Namensvergabe für Workspaces

Ob Du in Eurer Logik nun mit Präfixen in den Workspace-Namen arbeitest, ist natürlich Dir überlassen. Bedenke jedoch bitte, dass der Name des Workspaces, später auch der Name der App ist, die Du veröffentlichen wirst. Es ist also nicht sinnvoll, hier den Begriff „Workspace“ innerhalb der Bezeichnung zu verwenden, weil auch dieser dann im Namen der App auftaucht.

Kleiner Fun-Fact:

Workspaces derselben Version (V1 oder V2) können nicht denselben Namen tragen. Jedoch ist es möglich, dass es zwei Workspaces gibt, einer V1, der andere V2, die beide denselben Namen tragen. Sofern Du beide Versionen von Workspaces im Einsatz hast, gib bitte darauf Acht, dass derselbe Name nicht doppelt auftaucht.

Die Größe eines Workspaces

Sofern Du mit Power BI-Pro unterwegs bist – ihr also kein Premium im Hause habt – stehen jedem Workspace maximal 10 GB an Speicherplatz zur Verfügung. Auch dies kann eine limitierende Komponente sein, die zur Erstellung verschiedener Workspaces zwingt. Unter Power BI Premium sind andere Speichermöglichkeiten vorhanden, die sich in naher Zukunft sicher noch stark erhöhen werden. Microsoft hatte beim diesjährigen Business Application Summit ja geradezu riesige Größen für Datasets angekündigt. Die müssen ja auch in einen Workspace passen. Der folgende Screenshot zeigt Dir, wie Du den zur Verfügung stehenden Speicher Deines Workspace ermitteln kannst.

Sofern der Workspace selbst mit einem sprechenden Namen und einer passenden Beschreibung versehen wurde, wird es Zeit, andere Kollegen in diesen Workspace einzuladen. Das Stichwort heißt schließlich Kollaboration, also Zusammenarbeit!

So berechtigst Du Nutzer für einen Workspace

Alleine in einem Workspace zu arbeiten ist zwar nicht unsinnig – schließlich ist er die Basis für die Veröffentlichung einer App an eine (potentiell) große Anzahl von Berichtskonsumenten – dennoch ist der Workspace für die Zusammenarbeit gedacht. Daher ist es wahrscheinlich, dass Du auch andere Kollegen in diesen Workspace einladen möchtest. Und so geht’s:

1. Klick auf Zugriff,
2. Eingabe der E-Mailadresse des Kollegen (so wird er im Power BI service identifiziert),
3. Zuweisung der Rolle (dazu gleich mehr).

Bei den unterschiedlichen zur Verfügung stehenden Rollen innerhalb des Workspaces, stellt sich sicherlich die Frage, was hinter jeder Rolle steht und wie man sie am geschicktesten auf die Kollegen verteilt. Diesen Fragen gehe ich jetzt nach.

Rollen innerhalb eines Workspaces

Zum gegenwärtigen Zeitpunkt gibt es in einem V2-Workspace vier Rollen:

• Administrator (engl. Administrator),
• Mitglied (engl. Member),
• Mitwirkender (engl. Contributor),
• Anzeige (engl. Viewer)…. Hier hat die deutsche Übersetzung versagt 😯

Diese vier Rollen haben unterschiedliche Rechte, die ich in der folgenden Darstellung im Detail aufzeige:

Die Zuweisung der Rollen auf Kollegen kann dabei wie folgt aussehen:

• Administratoren – Wer den Workspace anlegt, ist automatisch Administrator. Sollte diese Person aus irgendeinem Grund nicht mehr Administrator sein wollen, muss sie zuerst einen anderen Kollegen zum Administrator machen, bevor sie eine geringere Rolle einnehmen, oder den Workspace verlassen kann. Kollegen, die in der Lage sein sollen, Workspaces zu löschen, oder andere Administratoren zu benennen, sollten diese Rolle erhalten. Der Administrator ist zudem die einzige Rolle, die Kollegen aus dem Workspace entfernen kann.
• Mitglieder – Während der Administrator im Wesentlichen die technische Verantwortlichkeit für den Workspace trägt, kann das Mitglied die inhaltliche Verantwortung für den Workspace übernehmen. Mitglieder sind, im Gegensatz zum Mitwirkenden und Viewer, in der Lage die im Workspace beinhalteten Power BI-Artefakte über die App zu veröffentlichen. Sie verantworten also die Korrektheit der Berichte, die an die Konsumenten gelangen.
• Mitwirkende – Der Mitwirkende ist in der Lage, in Power BI Desktop erstellte Datenmodelle und Berichte in den Workspace hochzuladen und dort auch zu bearbeiten. Diese Rolle hat gestalterische Berechtigungen, ist jedoch nicht in der Lage, Inhalt zu veröffentlichen.
• Viewer – Diese Rolle ist erst vor kurzem von Microsoft ergänzt worden. Hierbei handelt es sich um eine Rolle, die ausschließlich Leserechte innerhalb des Workspace besitzt. Hierfür kommen Personen in Frage, die reine Qualitätskontrolle über die erstellten Inhalte vornehmen sollen. Im Gegensatz zu den anderen drei Rollen, die allesamt in der Lage sind, die vollumfänglichen Datasets in Form der pbix-Datei herunterzuladen, greift beim Viewer eine definierte Row-level security. Sofern also ein Berechtigungskonzept integriert wurde, darf der Viewer nur die Daten sehen, für die er berechtigt wurde. Alle anderen Rollen sehen im Workspace immer alles. Falls Du dazu mehr erfahren möchtest, lies hier meine Reihe zur RLS.

Solltest Du die Rolle eines Kollegen einmal ändern, oder diesen gleich komplett aus dem Workspace entfernen wollen, dann kannst Du dies wie folgt vornehmen…

So entfernst Du ein Mitglied des Workspaces bzw. änderst dessen Rolle

In Abhängigkeit der Rolle, die Du selbst in diesem Workspace inne hast, kannst Du Kollegen aus dem Workspace entfernen, bzw. deren Rolle innerhalb des Workspace ändern:

• Kollegen zum Administrator machen – hierfür musst du selbst Admin des Workspace sein
• Kollegen zum Mitglied machen – Hierfür musst Du Administrator oder Mitglied des Workspace sein
• Kollegen zum Mitwirkenden machen – Hierfür musst Du Administrator oder Mitglied des Workspace sein
• Kollegen zum Viewer machen – Hierfür musst Du Administrator oder Mitglied des Workspace sein
• Kollegen aus dem Workspace entfernen – Hierfür musst Du die Rolle des Administrators haben. Wie das Entfernen funktioniert, zeigt der folgende Screenshot:

Manchmal kann es notwendig sein, einen existierenden Workspace wieder zu löschen. Wie das funktioniert, zeige ich Dir jetzt.

So löschst Du einen Workspace

Ein Workspace kann nur durch einen Administrator des Workspaces gelöscht werden. Der folgende Screenshot zeigt, wie Du vorgehen musst:

1. Du klickst auf Einstellungen
2. Falls Du Admin des Workspace bist, erhältst Du die Möglichkeit, diesen zu löschen.
3. Bist Du kein Admin des Workspace, siehst Du die Schaltfläche zum Löschen des Workspace erst gar nicht.

Manchmal willst Du einen gelöschten Workspace wiederherstellen. Lies weiter und schau Dir an, wie das geht.

So stellst Du einen (versehentlich) gelöschten Workspace wieder her

Manchmal löscht man einen Workspace und stellt danach fest, dass das wohl falsch war. Wie auch immer. Es gibt Mittel und Wege, einen gelöschten Workspace wiederherzustellen.

Nach dem Klick auf „Wiederherstellen“ kannst Du weitere Einstellungen für den Workspace vornehmen.

1. Übernahme des alten Namens, oder Vergabe eines neuen Namens,
2. mindestens das Hinzufügen eines (3) Administrators (im Zweifelsfall Dich selbst):

Es gibt zu dieser Thematik sicherlich noch viel mehr zu sagen, aber mit diesen Informationen ist man erstmal handlungsfähig. Wie geht Ihr bei Dir mit Workspaces um? Welche Logiken habt Ihr bei der Namensvergabe und was hat Dir in diesem Beitrag vielleicht noch gefehlt? Ich bin auf Dein Feedback gespannt.

Der nächste Beitrag wird sich mit der tatsächlichen Zusammenarbeit an Power BI-Artefakten beschäftigen. In Kombination mit dem vorliegenden Beitrag sollte sich damit ein relativ rundes Gesamtbild von Workspaces ergeben.

Bis zum nächsten Mal und denk dran: Sharing is caring. Wenn Dir der Beitrag gefallen hat, dann teile ihn gerne. Falls Du Anmerkungen hast, schreibe gerne einen Kommentar, oder schicke mir eine Mail an lars@ssbi-blog.de

Viele Grüße aus Hamburg,

Lars

Lars Schreiber

Lars ist Berater, Entwickler und Trainer für Microsoft Power BI. Er ist zertifizierter Power BI-Experte und Microsoft Trainer. Für sein Engagement in der internationalen Community wurde Lars seit 2017 jährlich durch Microsoft der MVP-Award verliehen. Lies hier mehr…

ssbi-blog.de

Der Beitrag Arbeitsbereiche in Power BI: Alles was Du wissen musst – Administration erschien zuerst auf THE SELF-SERVICE-BI BLOG.

Als Abonnent meines Newsletters erhältst Du die Beispieldateien zu den Beiträgen dazu. Hier geht’s zum Abonnement des Newsletters!

Was bedeutet „Freigeben“ im Power BI-Kontext?

Bei den unterschiedlichen Szenarien, wie im Power BI-Service Inhalte freigegeben werden können, geht es darum, die folgend aufgeführten Power BI-Artefakte mit anderen Personen (nicht zwangsläufig Kollegen im eigenen Unternehmen) zu teilen:

• Dataset
• Reports
• Dashboards

Datasets selbst, können gegenwärtig nicht freigegeben werden. Sie sind stets die Basis zweier weiterer Artefakt, den Reports und Dashboards, um die es im Wesentlichen geht, wenn von Freigeben die Rede ist. 

Ich beginne mit der einfachsten Form des Freigebens, dem spontanen Freigeben.

Szenario #1: Spontanes Teilen von Reports und Dashboards

Zweck

Spontanes Freigeben kommt zum Tragen, wenn sich der Chef meldet und innerhalb der nächsten 5 Minuten einen Bericht haben will, von dem er eben noch gar nicht wußte, dass man ihn hat. Der Adressatenkreis ist eingeschränkt und das Freigeben findet spontan, also ungeplant statt.

Rechte

Der Empfänger des Reports/ Dashboards hat ausschließlich Leserechte.

Lizenz

Der Sender des Reports/ Dashboards benötigt in jedem Falle eine Power BI Pro-Lizenz.

Der Empfänger benötigt generell ebenfalls eine Power BI Pro-Lizenz. Sofern sich der zu teilende Inhalt auf einem Workspace mit Premium-Kapazität (in einer sog. P-SKU) befindet, ist für den Empfänger die kostenfreie Power BI Free-Lizenz ausreichend.

Adressierung des Empfängers

Die Adressierung des Empfängers kann auf drei Wegen erfolgen:

• E-Mailadresse,
• O365-Verteilerliste (nicht O365-Gruppe!!!)
• Azure Active Directory Security Group

Szenario #2: Zusammenarbeit in App-Workspaces (App-Arbeitsbereichen)

Was ist ein App-Workspace?

Ein App-Workspace ist ein Container für …

• Power BI-Artefakte (Datasets, Reports, Dashboards, Dataflows (seit 5.11.18 in Preview)
• Excel-Arbeitsmappen („Excel-Daten in Power BI importieren“ & „Excel-Datei nach Power BI hochladen“)

Im Gegensatz zum Freigeben von Reports und Dashboards geht es bei App-Workspaces nicht nur um das Konsumieren von Inhalten, sondern um das aktive Mitarbeiten an eben solchen. Kollegen, die für einen App-Workspace berechtigt werden, erhalten eine entsprechende Rolle. Diese Rolle bestimmt ihre Rechte innerhalb des App-Workspaces. Bevor ich im Detail auf die unterschiedlichen Rollen und Rechte eingehen kann, muss ich zunächst erklären, warum es gegenwärtig zwei unterschiedliche Versionen von App-Workspaces gibt (App-Workspace V1 und App-Workspace V2) und worin ihre Unterschiede bestehen.

App-Workspace V1 vs. V2

Derzeit gibt es zwei Varianten des App-Workspaces: V1 und V2. Bei der V1 handelt es sich um die „alte“ Version des App-Workspaces, bei der V2 um die neue Version, die sich gegenwärtig noch in Preview befindet. Wieso hat Microsoft sich entschlossen, eine neue Version des App-Workspaces zu erstellen? Das hat im Wesentlichen zwei Gründe:

• Die V1 wird auf Basis einer O365-Gruppe erstellt. Diese Tatsache nervte sowohl Power BI-Nutzer, als auch O365-Admins, da bei jeder Erstellung eines neuen App-Workspaces automatisch eine neue O365-Gruppe erstellt wurde, umgekehrt aber bei jeder Erstellung einer neuen O365-Gruppe auch automatisch ein neuer App-Workspace in Power BI auftauchte. Diese Problematik ist mit der V2 behoben, die nun von O365-Gruppen entkopppelt ist.
• Die V1 ist hinsichtlich der Rechtevergabe an Mitglieder des App-Workspaces recht unflexibel, da hier die Rechte sowohl von der Rolle des App-Workspace-Berechtigen (Admin oder Mitglied), als auch von der Sicherheitseinstellung auf Workspace-Ebene abhängt. In der V1 ist es z. B. unmöglich bei zwei Kollegen mit der Rolle Mitglied einmal Leserechte und einmal Schreib-/Leserechte zu vergeben. Diese Problematik wird durch die V2 adressiert.

Tipp: Da auf lange Sicht alle App-Workspaces durch die Nutzer (nein, das macht nicht Microsoft für Dich) auf die V2 umgestellt werden müssen, empfehle ich, neue App-Workspaces gleich als V2 anzulegen.

Zweck

Gemeinsames Arbeiten an Power BI-Artefakten. Es geht nicht mehr nur um das reine Betrachten fertiger Reports und Dashboards, sondern um das Mitwirken/ Kollaborieren an Power BI-Artefakten. Daher auch die Bezeichnung „Workspace“, also „Arbeitsbereich“. Hier wird wirklich gearbeitet.

Rechte

Die Rechtevergabe unterscheidet sich zwischen beiden App-Workspace-Versionen stark

• V1: Kombination aus der Rolle des Kollegen (Administrator oder Mitglied) und der Erteilung von Schreib- oder Schreib-/Leserechten auf Workspace-Ebene
• V2: Die Rechte des Kollegen finden ausschließlich auf Rollenebene statt. Um hier feiner die Berechtigungen steuern zu können, wurden in der V2 zusätzlich zu den Rollen Administrator und Mitglied noch die beiden Rollen Mitwirkender und Viewer (wird erst integriert, wenn V2 nicht mehr in der Preview ist) ergänzt.

Die Unterschiede zwischen den einzelnen Rollenkonzepten in V1 und V2 verdeutlicht die folgende Übersicht:

Lizenz

Jeder Nutzer, der eine Berechtigung für einen App-Workspace haben möchte, benötigt eine Power BI Pro-Lizenz, unabhängig davon, ob das Unternehmen Power BI Premium hat, oder nicht. Dies bedeutet, dass auch für das Anlegen eines neuen App-Workspaces eine Power BI Pro-Lizenz notwendig ist.

Adressierung des Empfängers

Die Adressierung des Empfängers unterscheidet sich zwischen den beiden Workspace-Versionen:

• V1: E-Mailadresse
• V2: E-Mailadresse, unterschiedliche O365-Gruppen, Azure Active Directory Security Groups

Row Level Security

Simpel formuliert, handelt es sich bei RLS um die Möglichkeit, je Datensatz im Datenmodell festzulegen, wer diesen sehen darf. Falls Du hierzu mehr lernen möchtest, findest Du detaillierte Informationen in meiner Beitragsreihe zu diesem Thema. 

Wurden Reports/ Dashboards aus einem App-Workspace heraus veröffentlicht, dann gibt es Konstellationen, unter denen Nutzer des App-Workspaces in der Lage sind, die vollständige, den Reports/ Dashboards zugrundliegende pbix-Datei herunterzuladen. Diese Konstellationen sind die folgenden:

• V1: Nutzer des App-Workspaces hat die Rolle Admin, oder Nutzer des App-Workspaces hat die Rolle Mitglied, bei Schreib-/Leserechte auf App-Workspace-Ebene
• V2: Nutzer des App-Workspaces haben die Rollen Admin, Mitglied oder Mitwirkender

Es verwundert nicht, dass es bei diesen Kollegen sinnlos ist, ein Berechtigungskonzept auf Datensatzebene (also Row Level Security) zu  hinterlegen, da sie aufgrund ihrer Rolle sowieso auf alle Daten zugreifen können. Wundere Dich also nicht, wenn Du einen Kollegen in Deine RLS-Rollen integriert hast und er/ sie in geteilten Reports/ Dashboards trotzdem alle Daten sehen kann. Dann liegt es daran, dass er/ sie im entsprechenden App-Workspace, aus dem die Reports/ Dashboards geteilt wurden, eine Rolle hat, die ihn/ sie alle Daten sehen lässt.

Der Einfachheit halber, habe ich die oben beschriebenen Inhalte noch einmal tabellarisch zusammengefasst:

Widmen wir uns nun der dritten Variante des Teilen von Power BI-Artefakten.

Szenario #3: Freigeben von Reports/ Dashboards über Organisations-Apps

Was sind Organisations-Apps?

Microsoft tut sich mit der Namensgebung manchmal etwas schwer, was dann zu Lasten der Nutzer geht. Neben den sog. Service Apps, die es mir ermöglichen Webservices wie Google Analytics in Power BI mit wenigen Klicks zu importieren und der Power BI mobile App, die mich Power BI-Inhalte auf meinem mobilen Endgerät betrachten läßt, gibt es auch noch die sog. Organisations-Apps. Diese Apps sind quasi die veröffentlichte Variante eines App-Workspaces (daher auch der Name „App“-Workspace). Ich kann innerhalb des App-Workspaces definieren welche Artefakte Bestandteil der App sein sollen (1) und dann die App veröffentlichen (2). Eine App ist immer an den App-Workspace gebunden, aus dem Sie veröffentlicht wurde. Es gibt keine Möglichkeit, aus einem Workspace mehr als eine App zu veröffentlichen.

Zweck

Während das spontane Freigeben für Einzelfälle gedacht ist und App-Workspaces für die Kollaboration zwischen Kollegen, dienen Organisations-Apps der Verteilung von Inhaltspaketen an eine Vielzahl von Empfängern.

Rechte

Der Empfänger hat ausschließlich Leserechte.

Lizenz

Da Organisations-Apps aus einem App-Workspace heraus veröffentlicht werden, verfügt der Sender zwangsläufig über eine Power BI Pro-Lizenz. 

Der Empfänger benötigt generell ebenfalls eine Power BI Pro-Lizenz. Sofern die App aus einem  App-Workspace veröffentlicht wird, der auf einer Premium-Kapazität (in einer sog. P-SKU) beruht, ist für den Empfänger die kostenfreie Power BI Free-Lizenz ausreichend.

Adressierung des Empfängers

Die Adressierung des Empfängers kann auf drei Wegen erfolgen:

• E-Mailadresse,
• O365-Verteilerliste (nicht O365-Gruppe!!!)
• Azure Active Directory Security Group

Unterschied zwischen Workspace-Leser und App-Empfänger

Eine berechtigte Frage, die mir während eines Vortrags zu diesem Thema gestellt wurde war: „Wo liegt denn der Unterschied zwischen einem Nutzer mit reinen Leserechten im App-Workspace und einem Empfänger einer App?“ Aus meiner Sicht gibt es hier zwei Unterschiede:

1. Da ich in einer App nicht alle Bestandteile des Workspaces veröffentlichen muss, kann ein Nutzer mit Leserechten innerhalb des App-Workspaces Inhalte sehen, die ein App-Empfänger nicht sehen kann.
2. Da Inhalte meines App-Workspaces erst dann in der App erscheinen, wenn ich diese veröffentliche bzw. aktualisiere, hat ein Kollege mit Leserechten innerhalb des App-Workspaces entsprechende Informationen einfach zu einem früheren Zeitpunkt.

Beim nächsten Mal zeige ich Dir, wie man Power BI-Artefakte mit externen Nutzern teilen kann.

Bis zum nächsten Mal und denk dran: Sharing is caring. Wenn Dir der Beitrag gefallen hat, dann teile ihn gerne. Falls Du Anmerkungen hast, schreibe gerne einen Kommentar, oder schicke mir eine Mail an lars@ssbi-blog.de

Viele Grüße aus Hamburg,

Lars

Ich schreibe meine Beiträge für Dich, den Leser. Bitte schenke mir eine Minute Deiner Zeit und bewerte die folgenden Kategorien, um mir zu helfen meine Beiträge so gut wie möglich zu schreiben. Danke 🙂

Lars Schreiber

Lars ist Berater, Entwickler und Trainer für Microsoft Power BI. Er ist zertifizierter Power BI-Experte und Microsoft Trainer. Für sein Engagement in der internationalen Community wurde Lars seit 2017 jährlich durch Microsoft der MVP-Award verliehen. Lies hier mehr…

ssbi-blog.de

Der Beitrag Freigeben und Zusammenarbeiten im Power BI Service erschien zuerst auf THE SELF-SERVICE-BI BLOG.