It feels like the last couple of weeks all I’ve been doing is sowing chaos around Power BI and the Service. The reality is that we all must be aware of how the Power BI service works and what it brings to the table. The true power of Power BI is in the Service and in particular Apps. So let me pull some order together on that and see if it aids understanding. Finally, let us all consider the challenges that there seem to be in the current strategy.
Power BI Apps (now called Workspace Apps) are a secured version of selected workspace content. Yes, that sounds vague and nebulous, but we assure you the official definition is not better. Basically, when you create (or update) an app, you can select the reports and dashboards from that workspace that you want to include within the app. That set of content is then assigned to one or more audiences, before the app is published. Publication essentially means cloning the content and storing it separately from the workspace. This is a clone task as the item GUID remains the same, but the objects are no longer within the Group context but rather within a new “App” context.
This duplication is a one-way path, and there is no way to get that content back to an editable state. This “push” only activity WILL burn you at least once in your career. I have had content buried deep within Apps and ended up losing track of the core page or report that a senior leader used regularly. Meaning, upon an update when it changed, they were very much unimpressed. That is why I am now ultra cautious about what is to be done with Power BI App content.
The added challenge, that I always recommend is the concept of a “Single Pane of Glass”. This means that the content within the App will not remain related to a single workstream or process. The result is that it must be clear from within the content as to its source. This is a significant challenge and that terminology underplays the complexity. Once an App is published (or updated), any attempts you can no longer be certain of the exact source and content of the report. The simplicity of dashboards means that they can be easier, but as the “Tile Details” cannot be accessed, some content is again unable to be recovered.
Reports and their end user documentation is the only option. After going through many versions of end user documentation and attempting to come up with the most optimal solution there is only one option that is available. Documentation of the report page overlaying the page. This is a remarkably simple thing to do and the simple addition of two buttons (one to show and one to hide) allow for the establishment of a simple documentation strategy. Setting these up requires you to use Bookmarks and the Selection Pane.
Using this strategy, you can easily show your customers what the content is based on, and you can use additional elements to spell out exact source information. One thing that I always advice is to consider secondary reports as “disposable”, or rather not as part of the firmly controlled and governed elements that you should enact proper change management over. While there is method to this it must always be remembered that reports and their version history are important. It can be sensible to back up all the content that goes into an app, but it may not always be clear exactly what is in the app.
Should an app be restricted to content from a single data model or should it be something that we spread across multiple working areas or Semantic Models? The answer here will depend on who you speak to. Your customers will invariably tell you they want everything they need in a single place – Single Pane of Glass reporting (SPoG), while your technical teams will say an App per model so they can use DevOps as much as possible. NOTE: Workspace Apps do not support automatic updates.
In a data driven organisation the customer must come first because they are the ones we need to be support in being data driven. Ater all, while Data Analysts will consume the data, the true consumption is done by the business users who the insights are provided to. How they access and understand the data is key. So, our apps must be able to span Semantic Models, and we must formulate a mechanism that will allow us to capture what is being published and when. The manual nature of that publication may be good, or it may be bad. There may well even be a workflow that we can wrap around it all. These are organisation specific questions though.
Microsoft currently has Organisational Apps in preview. These have the ability to allow a business to publish multiple apps to a single workspace, making app management simpler. The challenge is that apps are locked to the workspace content, meaning ALL reports and Dashboards would need to be present for that to work. The management of which content should be published to which app over time seems to boggle the mind. We are not convinced that this is a step in the right direction.
Workspace Apps (which we currently have) are limited to only one app per workspace, but if you are using SPoG, and have functional team apps, how many app workspaces would even a large organisation have? Less than 20 would be our guess. If you consider an app per workstream and Organisational apps, you will likely end up with four or five apps per stream. Given that split is the preferred way of working at least ten different streams, that is at least double the app count with each customer needing to access multiple apps to get all their insights.
These are guess-timate numbers, but the reality would be you have more apps with the Organisational Apps and DevOps way of working. We are also still not convinced that Organisational Apps will be able to be automatically published or updated. So manual work will be needed to publish the content or more discipline will be needed to make sure content that has failed QA or is still in development does not make it into a production App.
Workspace Apps support Audiences, with each app being able to add 9 audiences, giving a total of 10 Audiences max. In practical terms these are a great additional, as they can make some difficult reports or apps simple. Think of a Regional Sales report – each region can be an audience with report level filters being configured and hidden, so each audience can quickly and easily see the content they need to see. Yes, this is not the same as RLS (Row Level Security), but it is significantly easier and does not add the long-term burden that RLS adds. All updates need to be validated with ALL roles (and combination of roles) going forward. RLS is great but does add a significant admin load.
Depending on how you structure content, audiences are a potential friend.
Geordie Consulting has worked with clients to help them get the most out of their Data, and Apps are one of the areas people struggle to get the most out of. Apps can serve up real insights in a simple and consistent way to help drive data to the front of any agenda. The challenge is always getting people to start to use them, and that is why it is so important that our customers feel they have ownership of their apps. After all, the more they back their data, the easier a data team finds their job. When the customers and data team do not align problems begin. This is why your Data Centre of Excellence must include a combination of business users and technical users – it fosters that agreement. We have the expertise and experience your organisation needs to maximise your success in business engagement. Our team will support not just the learning and development of your technical teams, but we can also support and train the business users within your organisation, setting up Super User Communities, simple training exercises and much more, all to bring data to the heart of your organisation and enable the success of your Data Centre of Excellence in the shortest time.
Book a Free Consultation Call with us and discuss how we can help you leverage effective Power BI Solutions to maximise the value of your data. Push your company to become data-driven with the help of Geordie Consulting.
