Happy new year! My first speaking engagement of the year is coming up January 20th at SPS St. Louis. If you’re nearby, be sure to register (it’s free!) and check it out on Saturday, Jan 20. Here are the three sessions at which you’ll find me:


Note: This, like many O365 things, is rapidly evolving. If you’re aware of better practices or new updates to licensing, feel free to mention it in comments.

I’m currently at SharePoint Fest Seattle where Chris McNulty, Sr. Product Manager for Office 365 and SharePoint at Microsoft, mentioned (as I understand) there could be changes coming to licensing that would allow more people to consume Power BI reports in a friendlier (more affordable) licensing structure. This would be amazing because currently:

I can create reports. People can’t view data in those reports in a secure way because the entire organization isn’t licensed for Power BI per person above the “free” license.

Specifically I, with a Power BI Pro license, can create reports and place those in SharePoint’s new page experience Power BI web parts (in Preview) but other people (with free or without Pro licenses) cannot view them. They see the following:

powerbiviewerror.PNGOf course, to me as the creator and properly-licensed individual, I see the report perfectly embedded as it should be. And not every organization can afford to license every single user appropriately to be able to simply view embedded reports. Especially if consuming reports (not sharing or building) is the only function they need in the Power BI realm.

In this post, I’ll cover:

  • How to embed Power BI reports the normal, easy (but license-exclusive) way
  • Why the webpart (normal, easy way) is cooler than embedding a script
  • How to embed the report in a (less secure) way so that non-licensed or free-license individuals can actually view and manipulate the data

In one of my projects, we built a directory largely based on this article with content created by Stacy Deere-Strole of Focal Point Solutions. Something we ran into was wanting to include multiple departments in our base search query (not refiners, as that only narrows our results instead of expanding them). We also wished to eliminate multiple results in the JobTitle property within the query text. While this is a simple solution, hopefully it will save you some trial and error in writing your search language.

You may have several forms or lists using dropdown menus across your site that you would have to update if, say, an individual resigned, or a department changed its name, or a building relocated. Manage this type of information (individuals, departments, buildings, etc. frequently used in lists and forms)  in separate lists that we’ll then use to create site-wide lookup columns to replace the many individual dropdowns across our sites that are repetitious. Basically, we’ll update the information in one place and know that it’s updated everywhere it’s needed across our site (or site collection if you’re familiar enough to go the extra mile with collection content types or Microsoft Flow, if your permissions aren’t at the site collection level).