This is a contribution to the Power BI Year in Review Contest 2017. The report will give you a wide range of insights regarding President Trump’s tweeting behavior throughout the year. The main data source for the report is from http://www.trumptwitterarchive.com/archive. Sentiment analysis and key phrase extraction has been done on the tweet text using Azure Cognitive Services. The result is embedded below. Give it a thumbs up at Power BI Data Stories Gallery.
When Power BI is introduced in an organization as self-service platform, a number of questions arise on how to organize content in the best way. The challenge is to provide a framework that clearly differentiate between IT-governed and self-serviced reports. At the same time, we need to provide our end-users with the cleanest and easiest to use structure.
In Power BI, we have the two central concepts – workspaces and content packs. However, it is not always obvious how we should utilize them in the most structured way.
The following illustration shows my best-practice setup for self-service using content packs and workspaces in Power BI.
In most cases we are working with four different actors:
- Consumer – only consuming information from reports and dashboards.
Typically, 70-90% of the users.
- Self-Service User – creating reports for consumers to use.
Typically, 10-20% of the users
- Data Scientists – creating new data models and introducing new data entities, for themselves or others to use.
Typically, 0-5% of the users.
- Developer – responsible for the whole analytics architecture, including the common analysis models and IT-governed reports.
You need to have at least one developer workspace. The purpose of this workspace is to structure and manage IT-managed content packs.
Furthermore, you typically create different workspaces for different information areas (finance, hr, sales, etc.). In order to differentiate between consumers and self-service users you need to create a separate self-service workspace for each information area. When new reports are ready in the self-service workspace they can be updated to the consumer workspace via a content pack.
There are two types of content packs – the ones that are managed by IT (A4) and the ones that are created using self-service (D). These content packs are updated individually and the responsibility for them are manage by different actors.
Detailed description of each step
(A1) The developer is creating reports in Power BI Desktop. In order to store the reports in some kind of source control repository, Power BI Desktop is currently a must. Power BI Desktop files is also key for being able to publish reports to different environments (dev/test/prod).
(A2) The Power BI Desktop file is published to the developer workspace.
(A3) The developer creates content packs from one or many published Power BI Desktop reports (and possibly dashboards).
(A4) The IT-managed content packs are made available for others to use.
(B1) The Data Scientist creates his own data model and report in Power BI Desktop.
(B2) The model and report is published to the self-service workspace.
(C) The Self-Service user is creating reports from existing data sources.
(D) The reports (and possibly data models) are made available in content packs for others to use.
(E) The published content packs are instantiated on consumer workspaces.
(F) The consumer uses the reports (coming from different content packs) in group workspaces or my workspace.
This structure is the way I have found being most efficient in managing IT-governed and self-service content in Power BI. It also provides the largest end-user group (consumers) with the cleanest workspaces.
Let me know what you think. How are you managing content in Power BI?
Recently Gartner published their latest BI Magic Quadrant for 2017. The below report is created in Power BI and visualizes the progress for the last ten years.
The short story
AutoSPFilePublisher is a SharePoint tools that synchronizes local files with SharePoint libraries. It makes it possible to work with source controlled SharePoint files locally and automatically keep site collections libraries in sync with the local files. The target group for AutoSPFilePublisher is SharePoint developers.
Use the comment section to provide feedback.
For the long story, continue reading.
SharePoint development involves a lot of creation and modification of SharePoint “core files”, such as files in a site collection’s Master Page Gallery. Most developers use one of the following three methods when adding or modifying SharePoint core files:
- SharePoint Designer.
- Explorer View, using Internet Explorer.
- PowerShell upload and publishing script.
There are certainly pros and cons with each of the above methods. Let me summarize my experience of each method:
SharePoint Designer and Explorer View (very similar, thus treated the same)
|+||Quick. It is an easy and integrated user experience to get direct access to a single file and update it.|
|–||No source control support. The file is always edited in SharePoint, which means you will have to download it to source control it|
|–||You have to publish the file manually, which in some cases are good but in most cases a source of error.|
|–||You must manually edit each instance of the file in all site collections it is used in.|
|+||Source control support. You have your source code files in the source code repository and upload/publish them to SharePoint from there.|
|+||Publishing and uploading the file can be done in one single step to avoid unpublished core files.|
|+||Publishing/uploading can be done to multiple site collections since its all controlled by the script.|
|–||Slow and manual. You need to manually start the PowerShell script each time you need to upload/publish files to SharePoint.|
|–||Script maintenance. You need to create and maintain the PowerShell scripts that takes care of the upload/publish process for you.|
The SharePoint Designer/Explorer View way is very appealing thanks to its quick and easy way to use, whilst the PowerShell way is much more robust and is preferred as soon as you put your source code in a repository.
I want a tool that is both quick and robust. Since none of the above methods supports that, I decided you create a tool called AutoSPFilePublisher.
The purpose of AutoSPFilePublisher is to automatically keep local files in sync (one-way only) with SharePoint libraries. AutoSPFilePublisher will automatically recognize if a file is changed locally and take care of the uploading and publishing for you.
This is what the main interface looks like. As soon as you click Start it will keep track of changes in all active configurations. If you want to add a bunch of files manually you can use the Add button (note that it will take long time to upload a lot of files).
This is what the configuration page for each SharePoint library looks like.
Please give the application a try, but note that it is a PREVIEW application. I take no responsibility for potential bugs. I recommend you use it in a test environment.