Tag Archives: Power BI

The Difference Between Reporting and Analytics is 42

In his novel “The Hitchhiker’s Guide to the Galaxy”, Douglas Adams envisioned a giant supercomputer named “Deep Thought” that was built to solve the answer to the ultimate question of life, the universe and everything. For the 5 people out there that are unfamiliar with the story, I’ll relate the important bits here. Deep Thought was commissioned by a race of pan-dimensional beings and required seven and a half million years to complete its calculations. When it was finally complete, Deep Thought informed the ancestors of the original creators that the answer was 42. The receivers were understandably disappointed with this response, and when they questioned Deep Thought further, the computer postulated that perhaps the problem was that they never really knew what the question was.

Undeterred, the race then commissioned a second computer (which happened to be the Earth) that would calculate the ultimate question. After a couple of 10 million year attempts, the ultimate question was determined to be “What do you get when you multiply six by nine”. Of course, Adams never claimed that the universe made sense.

To my mind, this is an excellent demonstration of the difference between reporting and analytics. The accurate answer (report) provided a result, but not meaning. Further analytics were necessary to determine context.

Like many information technology terms (Big Data, machine learning, CRM) Business Intelligence (BI) is one of those umbrella terms that many people use regularly without fully understanding its meaning. BI is comprised of many tools that help to glean information and insights from raw data. Thus, an ETL package that moves data from one location to another is just as much a BI tool as is a fancy looking infographic. Combine this lack of clarity with the overloading of the term “reporting, and we wind up with some real confusion in this space.

Reporting is the process of using data to highlight things or trends that have already happened. This can be contrasted with monitoring, which does the same for things that are happening now, and predictive analytics, which tries to predict what will happen in the future based on the same data. The difference between reporting and monitoring is only one of data latency, and as such, monitoring is often referred to as real time reporting, which further muddies the water. However, for the purposes of this article, I want to focus on historical reporting.

Reports are typically one of two types, either operational or analytical. Tools that are good at producing one type are typically not so good at producing the other. What’s the difference? Operational reports are designed to provide information that we know we need, and analytical reports are designed to help us discover things that we didn’t know, or to help answer unanticipated questions. Operational reports are typically designed to be printed. They are typically well paginated, pixel perfect, and provide a single view of the data within any given report. Analytical reports are just the opposite. They are designed with visuals as a starting point, but allow for the ability to pivot on or drill down into the data as appropriate to answer ad-hoc questions. Printing is typically a weakness for analytical reports, whereas drilldown is a weakness for operational reports.

Both report types have their place but they both have very different design point. The data that backs an operational report should ideally be relatively flat, as that best reflects the report layout and helps with performance. Conversely, cubes and data models exist simply because a flat data structure does not adequately support analytical reporting. With analytical reporting, a user may at any point decide to view quantitative data (a measure) through the lens of a different facet (dimension). This difference is so great, that we need a different type of engine to support it. OLAP cubes and tabular models are both examples of this.

Another difference is the data that is necessary to support both report types. Operational reports tend to concern themselves with various levels of subtotals per the predefined facets. In a case like that, the data mart that backs the report only needs to store those subtotals. The granularity, or resolution of the data stored in the data mart does not need to exceed that of report that references it. Analytical reporting is different. Since users will be expected to drill down on data, from on dimension to another, or to filter the data according to increasingly granular facets, it is critical to store all of the data in the data mart backing the data model. We don’t know the level of resolution the analyst will need; therefore, all detail is required.

As a simple example of this, consider the case where we want to analyze some server log data over a period of time. We can pre-aggregate the data in the data model such that it stores the total of the log entries of various entries on a daily basis. There would need to be a total based on each dimension, but the overall data storage would be less than for the raw data. Such data would allow an analyst to spot trends over several days, but the decrease in resolution means that it will be impossible to spot any usage trends within a given day. If daily trends will never be necessary, then this doesn’t matter, but the nature of analytical reports means that the designer can never be sure.

The more that the source data for the report is pre-aggregated, the less that report becomes analytical in nature, and the more it approaches operational. This is regardless of the tool used; you can build either report type with any tool, it’s just that it may not be optimal.

The issue here is one of semantics. Semantics however are important in knowing what you are getting if reports are being provided to you. Calling something “Analytics” does not make it so. If you spin up a content pack in Power BI, and find that the underlying data model provides just enough dimensions and measure to construct the provided report, and that you can’t deconstruct the data in any meaningful way, what you have is a report, not analytics, no matter what the platform. As with anything, there is a trade-off between complexity and power. Given the nuances of this topic, it’s important to look under the hood to know what you are getting.

The answer “42” is perfectly acceptable if you already knew that the question was “what is 6×9?”. But if you want to know why, that takes a little more digging. You’d also know that there might be a data problem…

Analyzing Your WordPress Site with Power BI and Google Analytics

I was recently asked by Christian Buckley what my top 2016 blog posts were. No problem I thought, I just went back to my output for the past year, and pulled out the posts that I knew have had a lot of discussion or impact, and forwarded them on. At that point he asked how many views that each of those pages have had. Being a data guy, I suddenly felt like the shoemaker noticing that his children had been going barefoot.

I monitor my blog traffic with the built-in WordPress JetPack tools, StatCounter, and Google Analytics. They all work slightly differently, with StatCounter and JetPack being the most alike. I tend to rely on StatCounter for immediate stats (how many hits today, what’s popular today) and the Google stats for a longer time frame. StatCounter doesn’t persist my stats beyond a day, as I don’t have the pro version, and the JetPack stats don’t seem very extensible. Google Analytics seemed like the best place to begin, particularly because there is a pre-existing content pack for Power BI.

The Google Analytics Content Pack

I have used the Google Analytics (GA) content pack casually and for demonstration purposes since it was introduced with the Power BI launch in July 2015. It hasn’t changed much. Actually, as far as I can tell, it hasn’t changed at all. To use the content pack, you simply log into the Power BI service, select “Get Data”, select the “Services” tile, and select Google Analytics.

After you enter in your credentials by selecting oAuth2, Power BI will import your GA data into a data model, and populate a pre-configured report. The report consists of several pages, mostly focused on visitors to the site.

There are some interesting visuals out of the box, and there are more metrics available in the data model if you want to customize the out of the box reports. At the moment, any customizations that are made in this way are not portable, and with the content pack, data is only retained for 180 days, which means that year over year comparisons are not possible. The visuals don’t appear to have been updated since initial release, which means that many of the new Power BI UI enhancements are not there, but they too can be added through customization.

Generally, if you’re going to do a lot of customization, the best tool to use is Power BI Desktop. Reports can then be reused easily and are highly portable. Luckily, in addition to the content pack, Google Analytics also exists as a data source for Power BI Desktop.

Using the Google Analytics Data Source in Power BI Desktop

When Power BI Desktop imports data from GA, it imports all the data that GA has. There seems to be no agreement on how long Google will retain this data, but in practice, GA seems to retain all data since it was originally configured. In my case, that’s a little over two years now, which is fine for my analysis. The first step is to connect to and import the correct data. Start Power BI Desktop, select “Get Data”, choose the Online Services tab and choose “Google Analytics”.

Once you authenticate, you’ll be presented with all of the sites that are monitored by Google Analytics. You’ll want to drill down and open “All Web Site Data”. GA captures an awful lot of information, and the trick is to know what to grab. Grabbing everything won’t work as it only allows for 8 dimensions and measures in a single import. In my case, I am interested in PageViews and Unique PageViews measures, and the Page, Page Title and Landing Page dimensions (under the “Page Tracking” section) measures. In addition, I want the Date, Hour, and Minute dimensions from the Time section.

Once selected, w select OK, and edit the query, giving it a good name like “GA Data”. Finally, we can select “Close and Apply” and the data will be added. This procedure can take a little while depending on the quantity of data.

Once loaded, we need to do a little bit of work in the data model. We imported the dates from GA, but we’ll want to do year/month/day drilldowns, as well as use textual values for month names, day names etc. For that, the tried an true method has been to build a Date table. Power BI itself will actually do some of this automatically for you behind the scenes, but a custom table gives us the ultimate in flexibility. DAX (the Power BI modelling language) makes this very easy. We create a new table by first selecting the “Modeling” tab, and then the New Table button. This allows us to create a calculated table in the formula bar. First change the name from “Table” to something meaningful like “View Dates”, and then add the following formula:

ADDCOLUMNS (
 CALENDAR (DATE(2010,1,1), DATE(2025,12,31)),
 "Date As Integer", FORMAT ( [Date], "YYYYMMDD" ),
 "Year", YEAR ( [Date] ),
 "Month Number", FORMAT ( [Date], "MM" ),
 "Year Month Number", FORMAT ( [Date], "YYYY/MM" ),
 "Year Month Short", FORMAT ( [Date], "YYYY/mmm" ),
 "Month Name Short", FORMAT ( [Date], "mmm" ),
 "Month Name Long", FORMAT ( [Date], "mmmm" ),
 "Day Of Week Number", WEEKDAY ( [Date] ),
 "Day Of Week", FORMAT ( [Date], "dddd" ),
 "Day Of Week Short", FORMAT ( [Date], "ddd" ),
 "Quarter", "Q" & FORMAT ( [Date], "Q" ),
 "Year Quarter", FORMAT ( [Date], "YYYY" ) & "/Q" & FORMAT ( [Date], "Q" )
 )
 

Adjust the beginning and end dates to suit the data in question, click the check mark, and voila, instant date table. There will be a record for every date between the beginning and end dates. It’s a good idea to adjust the properties of some of the resultant columns for display, we want to sort the Month Name Long and Month Name Short columns by Month Number, and the Day of Week column by the Day of Week Number column. Any additional customizations can be made as necessary.

The next step is to establish the relationship between the Date column in the GA table, and the Date field in the new calculated date table. Simply click on the relationship builder icon, the drag and drop the Date column from one table to the corresponding column on the other.

At this point, we can create a visual that shows traffic over time. We create a column chart, and add Pageviews as the Value, then we add Year Month Short (which should be sorted by Year Month Number) to the axis, and we should see site all site traffic over time. Adding Date to the axis and stripping out all the dimensions except Day allows us to drill down on days for a selected month.

Although we can see our site traffic by month, we still can’t answer Christian’s original question, which was “what were the most frequently viewed posts written in 2016“. Google Analytics has no clue when the pages were created. It’s possible to try to imply it from the earliest viewed date for a given page, but the created date is available directly in WordPress. We just need to get the WordPress data into the data model. Thankfully, that is possible through the WordPress REST Add on.

Using the WordPress REST Add-On

REST support is available for WordPress as an add-on. The “WP REST API” is available in the add-on catalog, and on Github here. Once installed, all WordPress content (including posts) is available through a simple http GET request. This is something that’s fully supported by Power BI, and therefore all the relevant post data can be loaded into Power BI through this add-on.

From the Power BI Home tab, select Get Data, then “web” and then use the URL required to retrieve posts. For the blog that you’re reading, it’s https://whitepages.unlimitedviz.com/wp-json/wp/v2/posts. The query will return a list of records. However, there will only be as many records as WordPress shows by default. We need all of them. The add on-allows you to specify the number of posts per page, by adding the “per_page” parameter. Therefore, in our case, it’s https://whitepages.unlimitedviz.com/wp-json/wp/v2/posts?per_page=50 where 50 is the desired number of items per page.

The per_page parameter is all that you need if the number of posts to analyze is fewer than 100, but the limit of this parameter is 100. There is another parameter that can be added to the query, page= that will specify the page number. With this, and the posts per page parameter, it’s possible to get all the posts. There are a couple of ways to implement this in Power BI.

The ideal way is to an “M” function. With a function, you build up a query normally, and then you wrap it in another parameterized query using the advanced editor, passing in the page number as a parameter, and that parameter being used in the subsequent query. The function can then be called from each record of another table, thereby returning all the posts, which is exactly what we need. This approach works perfectly well in Power BI Desktop. Unfortunately, once the model and report are deployed to the Power BI service, it stops working. The Power BI service currently cannot refresh any query that uses replaceable parameters as part of the query.

The other way that this can be handles is to generate multiple queries that explicitly use the page= parameter. The number of queries necessary will be equal to the number of posts divided by 100, then rounded up to the next whole number. In my case, I have 230 posts, and therefor need 3 queries. Once created, all 3 queries can be merged into a single table. This approach is messy, and will require occasional maintenance, but it’s the only one that works for now. Let’s walk through the process.

We’ll start with the first query. As above, we use Get Data, select the Web source and enter the URL for page 1 and 100 posts per page. For this blog the URL is https://whitepages.unlimitedviz.com/wp-json/wp/v2/posts?page=1&per_page=100. The query should show a list of 100 records. Next, we need to turn the list into a table so that it can be expanded. Click the “To Table” button in the ribbon.

Click OK to accept the defaults, and then click the small expand button in the column header (Column1). Be sure to deselect the “Use original column name as prefix” before clicking OK.

At this point, all the post metadata from WordPress should be available. You can choose to keep all or only some of the columns, but the ones that we want to be sure to keep are date, slug, and title. Title needs to be expanded, so we should go ahead and do that – the procedure is the same as the step above, but only the title field is returned as “rendered”. It’s a good idea to rename it to Title. Also, it’s a good idea to set the data type of the Date field to Date/Time here.

Once the query is the way we want it, we’ll want to name it something like “Posts1-100”, and then we need to set its data load properties to not load into the report. We don’t want the data to load into this query because it will only be one merge source of three, and we don’t want to store the data redundantly. To do that, we right click on the query, select properties, and deselect “Enable load to report”. Then click OK.

We now need to duplicate this query for page 2. The easiest way to do this is by copying all the M script generated by the query builder into a new blank query, and then editing it. From the Home tab, we click on “Advanced Editor”, then select and copy all the text in the dialog box. We then close the dialog box, then select New Source – Blank Query. Once opened, we again select “Advanced Editor”, remove the default content and paste the copied text into the box. Finally, “page=1” in the URL is replaced with “page=2”.

We then save the query, name it and set the properties not to load as with the first query. We then repeat all these steps for page 3. At this point we are ready to merge the queries into our “master” query.

To merge the three queries into one, we select the “Append Queries” dropdown from the ribbon, and select “Append Queries as New”. We then select “Three or more tables” and add the three tables and select OK. Finally, we give this new query a name “Posts” but we do not prevent the data from loading. This is our master table. At this point, we are ready to Close and Apply, and return to the main design surface.

This Posts table has a Date column, but it’s actually a Date/Time column. To use a date table, we need to create a new calculated column with just the date portion. With the Posts table selector selected, we select the Modeling tab, and then “New Column”. We then give the column a name (PostDate) and the following formula based on the Date column:

We also want a calculated measure to indicate the number of posts. The process is like that for a new column. We select “New Measure”, and add the following formula to the formula bar:

Posts = CountA(Posts[id])

We will be relating records in the Posts table to records in the GA table, so we need another date table to keep the relationships clean. We could calculate another table as we did above, but it’s even easier to calculate the new one based on the one already created. We simply select “New Table” and use the following formula:

PostDates = ViewDates

Next, we create the relationship between the Posts table and the PostDates table the same way that we did it for the GA table above. Now that both tables are date sliceable, we need to relate them together. In the Posts table, the Link column uniquely identifies the page but the GA table uses the relative address of the page in the Landing Page column. In our case the solution is simple, we need to prepend the main part of the site address in question (in our case https://whitepages.unlimitedviz.com) to the Landing Page. We do that by creating a new column, URL, with the following formula:

URL = “https://whitepages.unlimitedviz.com” & ‘Google Analytics Views'[Landing Page]

Finally, we relate the URL column in the GA table to the Link column in the Posts table.

At this point the model is ready for use in reports.

Building a Report

How to build a report is not the focus of this article, so I’ll just explain the steps taken here. To prepare our data model, we first need to flag the Link column in the Posts table as a URL field. To do that, select it in the UI, then select the model tab. Use the Data Category Drop down control and select “Web URL”.

Next, add a new table to the reports, and in in the Format section, select Values, and set the “URL icon” setting to “On”.

This has the effect of displaying any column that has been flagged with the Web URL attribute as a link icon with a live hyperlink, instead of the entire, often long URL itself.

Next, we add the Title and Link fields from the Pages table, and the Pageviews field from the GA table, and then sort the table by Pageviews. Next, we add two slicer controls to the report – one bound to the Year column of the PostDates table, and the other bound to the Year column of the ViewDates table. Now by selecting 2016 from the ViewDate slicer, and 2016 from the PostDate slicer, we can see, in order with precise numbers, which posts authored in 2016 were most frequently viewed in 2016. With this, I was now able to give Christian an answer.

An answer today is one thing, but an answer next year is another altogether. This report was worth sharing, so it was worth sprucing up a bit. By taking advantage of some of the new table formatting capabilities in Power BI, and importing the chiclet slicer custom control, we are able to make a more visually appealing report. I will also occasionally use a column chart in a report and use it like a slicer when appropriate. With a little bit of formatting work, we wind up with a report that looks something like the following:

Publishing and Sharing

We’re now ready to publish this report. The easiest approach is to simply select the “Publish” button from Power BI desktop. Select the destination, most likely your personal workspace. When publishing is complete, we can select “View in Power BI” to see the report in the service.

Having the report is one thing, but we want this report to be kept up to date. To do this, we go to the datasets section and select our dataset. In the data source credentials, section, we need to set the credentials for both Google analytics, and our WordPress connection (which will display as “Web”). Even though the Web source is anonymous, we have to configure it that way in the Power BI service. Once the connections are configured they should appear in the Data source credentials section with no notices.

When we configured the WordPress data import above, we used 3 queries. That’s good for 300 posts, and my blog is currently at 238, which should be fine for a while. However, once I hit 300, I’m going to need another query. What I’m really hoping for is that by that time the Power BI service will support parameterized data sources for refresh, but either way I’ll need to modify the data source. I’m likely to forget this need about a week after I publish this post, so a reminder is a good idea. Luckily, Power BI supports data driven alerts, which is exactly what we need here.

Alerts are set on dashboard tiles for card date. Our report has a data card showing the number of total posts. Once that card has been pinned to the dashboard, an alert can be set on it for when it reaches a specific threshold. Simply hover over the dashboard card and click on the ellipsis, then the small bell icon.

In our case, we want to be notified when the number of posts are approaching 300, so we set the condition to be above 297. Once blog post 298 is published, I will receive an email and can then act on it.

Finally, I want to share this report with Christian so that the next time he has questions about my blog, he can just look it up for himself. When I tell him this, I’ll say that it’s so he can keep me honest, but really, I just want him to stop bugging me…

We don’t work at the same company and we use different Azure AD tenant. I could share the dashboard externally with him, but it’s even easier to share it anonymously, and anonymous sharing of this data is fine with me. Anonymous sharing of data is relatively straightforward. From the report interface, select File – Publish to web. A dialog will open asking for confirmation, and once opened will provide a URL that can be shared publicly. In the case of this blog’s report, you can simply click here to get the full report in a dedicated window. I can just email that report to Christian, and he’ll have the answers that he’s looking for. The beauty of anonymous sharing is that you are also given an embed code that can be added to any web page. As an example, the fully interactive report for this blog can be seen below.

So, You Can Disable Office 365 Groups After All

After my recent post “You Can’t Disable Office 365 Groups”, I received feedback from a few people, specifically Elaine Van Bergen,
Martina Grom and Joe Stocker that some editing controls have been added in through the tenant that allows Group creation to be disabled in the Office 365 tenant, and that these controls affect all of the user interfaces that can create groups. The procedure is outlined here, and Martina offers her insight on it here . I was a little disappointed that I had missed these newer controls earlier, but quite happy about the discussion that the original article started. It brought to light some of the confusion around this feature. In addition, it also highlights the fact that Office 365 Groups are about far more than just conversations, they are the bedrock of all Office 365 services moving forward.

Having said that, and having tested these new controls, I have a few observations to make about disabling Groups.

Much of the feedback that I received of my original article was “Good, they shouldn’t be disabled anyway, they’re too important”. To be sure the other side of that argument was heard from as well, but I tend to side with the former. For me at least, the group construct represents real value. It is a trade-off between ease of use and control to be sure, but as a container, it’s easy to understand, and relatively easy to work with for end users. The concerns around Groups are focused on governance, and those concerns are valid. If anyone can create a group anytime, and there is not process for organizing or classifying them in place, they can quickly get out of hand, producing islands of information all over.

The new management controls allow for a single security group (not an Office 365 group) to define those that can create Groups. Groups created by these members are available to all, but only these members can create new Groups. Only one security group can be flagged for group creation, so it’s an all or nothing proposition for these group members.

The article above walks through the process of creating these controls through PowerShell with the Microsoft Azure Active Directory Module for Windows. There are a couple of quirks when walking through this process. I found that the article itself contains a typo, the PowerShell command “Get-MsolCompanyInfo” should actually be “Get-MsolCompanyInformation”. In addition, when downloading the module itself, the 1.1.130.0 Preview version is required.

One would think that the GA version (1.1.166.0) would include everything necessary, but one would be wrong. I made the mistake of trying to use that version and I hit a wall. You need the preview version.

The Azure Active Directory management area in the new Azure portal also allows for the management of group creation rights. I was unable to use the interface to initially set these controls, but once set, the controls were reflected in the user interface, and it’s possible to manage them. Azure Active Directory management is still in preview in the new portal, so presumably this will improve at GA. The controls can be found in the Azure Active Directory blade under Users and Groups – Group Settings.

Like their predecessor, these controls don’t remove the option to create a group from the client interfaces. Once the “Create” option is selected, the user is usually notified that this will not be possible. In one case, it simply fails. The following are the different messages that users will receive when they try to create a new Group but are prevented from doing so.

Outlook Web Access

SharePoint

Planner

Power BI

Microsoft Teams

Ideally, the create option would simply be removed from the user interface, but at least these interfaces prevent the user from filling out details before failing with one notable exception. When a new Group Workspace is created in Power BI, the operation simply fails, and the user isn’t notified as to why. It almost seems as if the Power BI team wasn’t notified that these new controls exist.

The remaining workload that is (ok – will be) integrated with Groups is Yammer. With Yammer, when a Yammer Group is created, a corresponding Office 365 group will be created, and kept in sync with the Yammer group construct. This will ultimately be where Yammer notes and files are stored (via OneNote and OneDrive – basically SharePoint) as well as the group calendar (in Exchange). However, according to this Microsoft support article, if Office 365 Group creation is disabled, then the Yammer groups will not be Office 365 connected.

It therefore is now possible to prevent users from creating Office 365 Groups. This will be important to large organizations while they formulate an adoption strategy for Groups, but formulate it they should. Just because Groups can be disabled, it doesn’t mean that they should. Groups are by their very nature a compromise between usability and manageability, and centralizing creation tips the scales on the side of manageability. We’ve had this for a long time with classic SharePoint, and the usability of Groups is what’s so exciting from an adoption standpoint. Almost all innovations in the Office 365 space are now centered on Groups – they are the new foundational unit, and by ignoring them, you miss out on much of the future enhancements.

Caution is certainly advised, but it’s a good idea to move forward with a Groups strategy. Now.

You Can’t Disable Office 365 Groups

Note – Since originally publishing this post, I have been made aware of some new management tools that will allow the ability to disable group creation by default. As opposed to modifying this post, which contains other observations, I have published a new one dealing with these new tools here.

As I’ve discussed before, Office 365 Groups are a very important feature in Office 365, and one that all organizations using Office 365 should fully understand as soon as possible. Groups are either required or they provide important capabilities for every product in the Office 365 stack. However, every organization has a different tolerance for change, and some have no tolerance for it at all. In addition, there are many aspects of Groups that are still a work in progress (navigation for example). A frequently asked question is “how do we turn off Groups?”. There’s nothing in the Office 365 Administration interface in either the Groups, or the Services & Add-ins sections.

Groups Administration

Groups section in Services & Add-ins

I’m far from the first person to hear this question, and a quick Internet search will turn up many articles that walk through the process of “how to disable Groups creation”. There is an article on Technet that walks through the process, and Wictor Wilén has another that is quite straightforward (not to mention insightful). Finally, Albert-Jan Schot walks through the process of doing this for specific users or groups of users in the tenant.

What these approaches do is to adjust the Outlook Web Access policy that controls the creation of Office 365 Groups. At its core, an Office 365 Groups is just a type of Azure Active Directory Group, one with multiple services attached to it. When Groups were first introduced, the only way of creating them was through the Azure Active Directory interface, PowerShell and through Outlook Web Access (OWA). The first two methods require an administrative level of access, so enabling and disabling this feature in OWA effectively disabled it for end users. An end user can still see the Group creation controls, but any attempt to create a new group is met with a dialog informing them that this feature is disabled.

Since Groups were first introduced, there have been several significant changes as more Office 365 services embraced the Groups structure, and others have been introduced that rely on it.

When the “new” Power BI was introduced in mid 2015, its Sharing story relied heavily on Office 365 Groups. Each Group receives a Power BI workspace, and conversely each new Power BI workspace is a Group. Given that end users can create and to some extent manage the workspace directly in the Power BI user interface, it represents an alternate Groups management tool focused on the end user.

Creating a new Group in Power BI

Microsoft Planner, launched in mid-2016 is another product that relies on the availability of Groups. For the most part Planner stands on its own, with minimal ties to the rest of the Office 365 stack. Each Plan contains multiple tasks, but under the covers, each Plan is backed by an Office 365 Group, with all the rest of the available services. Creating a new plan in Planner creates a new Group, and everything that goes with it, even though the interface doesn’t make it very clear. You’re getting far more than just a plan.

Creating an Office 365 Groups (aka Plan) in Planner

With the release of Modern Team Sites in SharePoint, SharePoint is also very tightly bound to Office 365 Groups. Before this release, creating a new team site through the SharePoint interface or through the SharePoint administration interface created a classic SharePoint site collection. Doing so now also creates a group to go along with it (again, with everything that goes along with that) and all the access to the new Team Site (a site collection) is controlled through membership to that Group. The SharePoint interface for this makes it very clear as to what is happening – “Lets create a new team site and group”.

Creating an Office 365 Group from SharePoint

It is still possible to create a SharePoint site collection that is not bound to a group through the SharePoint administration interface. Modern team sites (the site collections created through the SharePoint user interface) don’t appear in the SharePoint administration interface at all.

The Outlook 2016 rich client also has a comprehensive set of group management features. A group can be created by right clicking on the “Groups” node in the Outlook mailbox, and once created can be fully managed by the “Home” tab in the ribbon.

Creating a new group in Outlook 2016

Managing a group in Outlook 2016

There are now 5 different way for end users to create and in some cases, manage their Office 365 groups. The original Outlook Web Access interface, and now Outlook 2016, Planner, SharePoint and Power BI. The processes outlined above for disabling group creation prevent group creation from Outlook Web Access, but what effect do they have on these new interfaces? The answer is, no effect whatsoever. Whether the “GroupCreationEnabled” OWA policy has been set to false or not, these other interfaces will still be able to create and work with Office 365 Groups. This may not be surprising as Power BI, Planner, and now even features of SharePoint are dependent on the Groups infrastructure.

I have not called out Microsoft Teams above. It is true that Teams is also dependent on the Groups infrastructure, and that creating a new team will create a new group. Where Teams differs from the other dependent services is that the creation of a new Group in one of the other interfaces does not automatically create a new Team. In addition, Teams itself must be enabled by an administrator, meaning that for this additional service, Groups creation can be controlled centrally.

In the very near future, Yammer will also become Groups dependent. Creation of a new group in Yammer will spin up a corresponding Office 365 group, which will be used to store the files and notes available in Yammer. These groups will be flagged as “Yammer managed” meaning that they will not appear in the Outlook interfaces, but they will be available to all the other services that utilize groups.

The bottom line of all this is that even if you use Office 365, and you think that you have disabled Groups in your tenant, the chances are that you could be in for a surprise. If any of these dependent services are in use, the chances are that you already have several created.

Groups are the bedrock of all new features in Office 365 moving forward – it is therefore a good idea that your organization understand them as soon as possible. Their inevitability is also another strong argument for paying close attention to them. If you are currently discussing whether or not they should be used, I would strongly encourage you to shifting that discussion to how they should best be used.

Understanding Office 365 Groups

When Microsoft Teams was announced at the beginning of November 2016, I posted an article that attempted to explain the different social networking products available from Microsoft and the advantages/disadvantages of each. Since then, it has become apparent to me that there continues to be a lack of understanding about what Groups are, what they bring to the table, and where they fall short. This post is an attempt to help clear up some of that confusion.

To begin with, Groups isn’t a product in an of itself, it’s an infrastructure. Specifically, an Office 365 Group is a specific type of group in Azure Active directory. That’s it. They have a few properties, and they contain members, but outside of Office 365 administration or Azure Active Directory admin, there’s really nothing to look at. What is unique about them is that the Office 365 services are becoming increasingly tied to them, and creating one of these groups will provision multiple artifacts in multiple Office 365 services.

The value of Groups is really in the workloads and services that they tie together. This is where it starts to get a bit confusing. The way that I see it, there are currently 9 workloads (team sites, file storage, group inbox, enterprise social, group chat, notebook, plans, calendar, and report workspace) offered by 6 different services (SharePoint, Outlook, Yammer, Microsoft Teams, Planner, and Power BI). Arguably, Group inbox, enterprise social and group chat could all be considered conversation spaces, but my earlier article makes the case for considering them separately. Also, Skype for Business is notable by its absence, but I consider Teams to be the logical successor to Skype for Business.

A summary of the different workloads, and the services that offer them can be seen below.

This is a description of the various workloads offered by the component services, and it’s relatively straightforward. The only overlaps (if my earlier assertions about the different types of social are accepted) are group inbox services being offered by both Outlook and Yammer. Since Groups created and managed by Yammer will be kept distinct from other groups, this shouldn’t be the source of too much confusion.

The picture gets a little murkier however when we talk about the way that users will interact with groups, which is through a client application of one form or another. All the constituent services have at least one client application that interacts with Groups, and several of these overlaps significantly. A full understanding of Groups includes an understanding of all the available clients.

SharePoint

When an Office 365 Group is created, a Modern SharePoint Team site, which is a SharePoint site collection gets created along with it. This site collection is home not only to the Group’s team site, but to its OneDrive file storage, and to its Notebook (via OneNote). The SharePoint home page is focused on site collections, with Group site collections being called out specifically. From here one can search for Groups, pin favourite Groups, access recently used Groups, and access Groups deemed important by the tenant administrators.

SharePoint has two different clients that touch Groups – the standard web interface and SharePoint mobile. As noted above, SharePoint supplies 3 of the core Group workloads so the SharePoint interface is inherently well integrated. In addition to the native interface, the SharePoint web part framework lends itself to further integration, and indeed there are already two Modern web parts that have emerged that tough other Group workloads. The Yammer web part, which is available today in first release brings enterprise social into the SharePoint interface, and the upcoming Power BI allows the embedding of reports into SharePoint pages.

Groups can be created and managed directly in the SharePoint interface, and group conversations are accessed though a Group conversations link. Now, this launches the Outlook Web App to access the inbox, but when Yammer Group integration is rolled out, it will launch into Yammer for Yammer managed Groups.

The SharePoint mobile application is full fidelity, and modern web parts work with it. Thus, the SharePoint mobile app has all the same touchpoints that the browser interface does with one exception. It is currently not possible to add or manage Groups in the SharePoint mobile app.

There is currently no integration of Group chat (Teams), Plans, or the group calendar in either the browser or the SharePoint mobile client.


SharePoint UI integration with Groups

Outlook

The Outlook web application was originally the only place to go to create Office 365 Groups. Management of Groups is therefore its strong suit and is provided natively. The Group inbox and the Group calendar are also both provided by Outlook (Exchange) and the web client reflects that. The Outlook clients are currently the only tools that allow these two workloads to be accessed natively. In addition to these native workload, the browser client provides contextual like to open the Group Team site, OneNote, OneDrive, and the Group Planner. There is currently no integration between the Outlook browser client and enterprise social (Yammer), Group chat (Teams) or Power BI workspace.

The rich Outlook client included in Office 2016 has almost full feature parity with the browser client. The only difference is that is does not currently provide links for opening the Group Team site, or Planner.

The Outlook mobile app, available on iOS, Android and Windows Mobile is a bit of an anomaly. This client does not integrate at all with Groups. Instead, the Outlook team has published an app on these platforms called “Outlook Groups”. Given that they are known as Office 365 Groups, this name can be a bit confusing. The Outlook Groups app provides native access for the Group inbox, Calendar, and OneDrive files. It will launch the mobile OneNote app for access to Group notes, and it even allows for Group management. It is the only mobile app that allows for Groups management.

Outlook UI integration with Groups

Yammer

Yammer has historically been a completely separate application, and its user interface reflects that. To date, there is no integration with Groups, but this work has been done, and it will be available shortly. An early build of the Groups integrated Yammer interface was recently demonstrated at the Microsoft Ignite conference in Atlanta.

Groups integrated Yammer client

The integration points can be seen in the right column of the UI. Initially, Yammer will integrate OneNote and OneDrive for notes and file storage respectively, and accessing the links will open the respective web applications. The “classic” Yammer files and notes will be maintained for a period and can be accessed at the top of the UI. In addition to files and notes, both Planner and the SharePoint Team site will be available directly from the Yammer interface. There is not integration at all with the Group Inbox, Group chat, Calendar or the Power BI workspace.

IT will be possible to create manage Groups and add/remove members directly from the Yammer interface. Creation of a Yammer group will spawn an Office 365 group, and while all operations will be performed in Yammer, they will be kept in synvc with the Office 365 Group. It should be noted that Groups that are created in the manner will be flagged as “Yammer managed” as opposed to “Outlook managed” and will be invisible to the Outlook clients. All the other clients will be able to see them however.

The Groups integrated mobile client has not been shown publicly yet, so we can only speculate on what it may contain. I suspect it will mirror the browser client, but for now, the only thing that is certain is that it will support enterprise social.

Yammer UI integration with Groups

Microsoft Teams

Teams is the new kid on the block. It is currently available in preview form, so this analysis may be incomplete. Microsoft Teams was built by the Skype product team, and given its ability to do 1:1 conversations, as well as textual, audio and video conversations, it should logically be seen as the successor to Skype for Business. What it brings to the table for Groups is a persistent semi-threaded chat interface. Although it only provides one of the workloads to Groups, it’s UI encompasses most of them.

The Teams client is quite rich, and it provides “sub-team” management. Every team gets at least one channel (General) and additional channels can be added at will. These channels are the containers for the semi-threaded discussions, and each channel also gets its own folder in the Groups OneDrive, as well as a section in the groups OneNote. Creating a channel provisions these artifacts automatically. Any one of these channels can be extended through tabs. Tabs are a way of including content that may be relevant to the channel, and that content can be dynamic. For example, a Power BI report can be added to a new tab and it will always be up to date, or through a third party, a Yammer Group conversation can be embedded as well. Finally, connectors can be employed to automatically add relevant content to a channel’s conversation interface as it occurs – a Twitter feed is a good example of this.

Teams channel showing the associated artifacts in OneDrive and OneNote

The fact that there is already a third-party tool for embedding Yammer conversations speaks to the extensibility of the Teams client as well. Extensibility options are available for tabs and connectors.

The integration of Teams with Planner is notable as well. As I previously wrote about here, the Teams client allows for multiple planner plans to be created within not only a single Group, but a single channel. These plans are NOT available through the Planner client UI, although the resulting tasks are. I would look for this to change in the near future, but that’s the way it works today.

The Teams client (both browser and desktop – they are virtually indistinguishable) has access to the widest set of Group workloads of any client currently. This is partly due to the fact that it is brand new, and as such, is the only client that has access to the Group chats. It has native access to Group management, file storage, group chat, notebook, plans and Power BI reports. It has links to the Group’s Team site, and through third party integration, it can embed enterprise social content. The only workloads that it does not currently integrate with are the Group inbox, and the Group calendar.

The mobile client is unfortunately vastly different. The only workloads that the mobile client works with today are Group chat (as expected) and Group files (from OneDrive. Given the importance of mobile to the modern team story, I would expect this to change. However, if the SharePoint mobile client had access to the Group chat, it could provide a viable alternative.

Microsoft Teams UI integration with Groups

Planner

There is very little integration between Planner and Groups. The Planner UI obviously offers native access to Group plans, but as mentioned in the Teams section, not all the plans – only the one associated twith the root Group itself. Each Plan also offers a link to access all of the files stored in the Group’s OneDrive, and that’s where the integration ends. There is no integration with the rest of the Group workspace. The Palnner browser client is also the only client available. Inexplicably, there is no mobile client for Planner.

Planner UI Integration with Groups

Power BI

Power BI makes very good use of Groups – Groups provides the optimal sharing option for Power BI. Each Group is provided its own Power BI workspace, which is a container for data sources, reports, and dashboards. All members of the group get access to all the assets contained within.

The Power BI browser client is aimed primarily at the use of the Power BI service, but does provide some integration with the other Group workloads. Groups can be created and members added from the Power BI UI (although they are referred to as Group Workspaces). Native access is obviously provided to all the Power BI assets contained within, and links are also provided to the Outlook browser client for access to the Group inbox and the Group calendar. Finally, Group OneDrive files are natively available for the storage of data sources. There is no integration with the rest of the workloads currently.

The Power BI mobile client is all about Power BI – it doesn’t integrate with any of the other workloads, aside from being able to use the Group workspaces themselves.

Summary

To summarize, the modern Office 365 Group provides the membership and access services to 10 separate workloads which are provided across six different products/services. This “Group workspace” is accessed through any of 14 different clients that provide varying levels of access to the different workloads/and services. The choice of client will depend heavily on requirements and will likely lead to a combination of clients based on capability and preference. At the moment, the most integrated browser client is provided by Microsoft Teams, and the most integrated mobile client is SharePoint mobile. A final summary is below.