Whilst the out of the box analytics from Microsoft are OK for a cursory inspection they simply do not go deep enough to yield real value. In order to uncover value we use TyGraph for Yammer. There are others in the market but TyGraph give us what we need.
The scope of our TyGraph analytics covers all of our Yammer Groups regardless whether they are listed as public or private. For this TyGraph provide two separate Power BI PBIX files:
- _ReportClosed for data relating to Public Yammer Groups. Private data is obfuscated in this model but the total number of Groups etc. is reported
- _ReportOpen for all data i.e. both Public and Private. No data is obfuscated
We provide open access for all staff to the public data using a Power BI App. We do not freely share the entirety of the private dataset. We do not share the private data in order to preserve the privacy of the conversations.
On request, we can provide a targeted subset of private data to the owners of a specific group. How we do this is the subject of this post.
Row Level Security
The Yammer analytics app includes a dataset that has been configured to use Row Level Security (RLS). RLS is used to trim the data to specific users and groups. The details of applying RLS to a Power BI dataset is described in this Microsoft article.
Listed in the Reports section is a report called ‘SuperUsers_Private’ which is used to display selected private Yammer data. Users are directed to the report to access the data. The Report was originally created by cloning the out of the box TyGraph Report.
The related dataset is called ‘SuperUsers_Private’. RLS is applied to this dataset:
RLS is managed by editing the PBIX file associated with the ‘SuperUsers_Private’ report. The PBIX file can be downloaded by App Owners from the File menu of the Report:
The report takes a couple minutes to download as it is around 125MB in size…
Once downloaded, the file is saved locally for editing and opened in Power BI Desktop. The configuration of RLS is accessed from the Modelling menu in the Ribbon:
Establishing and managing Roles
Roles are used to apply a specific set of filters. The filters restrict the data to the target Yammer groups. The Power BI documentation describes the process for creating roles. Each role in our model has access to a specific set of data.
TyGraph data and DAX Table filters
The dataset contains a number of Tables:
In order to limit TyGraph data to specific Groups it is necessary to apply Table Filters to:
- Activities
- Group Members
- Messages
- Metrics
- Threads
Logic would suggest that applying a Table Filters to:
- Files
- Groups
- Groups Shared To
- Notes
would be advisable. However this will result in visualisation errors owing to the way Relationships are defined in the model. The filters are applied through Manage roles:
The Table filter DAX expression filters the data based on the GroupID. This removes the risk where a Group is renamed. Thankfully filtering only needs simple DAX expressions
For example, to filter for a single GroupID:
[GroupID] = 13338219
To filter for more than one GroupID (This Group OR That Group):
[GroupID] = 13338219 || [GroupID] = 9020365
Effect of Relationships
It is important to note that owing to the way TyGraph have defined Relationships in the model several items may still display names of Groups that are outside of the Role definition. In particular:
- Slicers using fields from the Groups table
- Most Engaged Groups metric
- Most Engaged Members metric
However the messages and activities that are outside of the Role definition will not be displayed. This is acceptable to us as message content is not exposed. This is overcome and the presentation of the Report tidied up using a Report level filter that includes the Groups used in the Role definitions:
Note that a user could delete this filter in the published report thinking that it would expose more data. However RLS will prevent out of Role data from being shown. The worst that happens is the Group names are revealed which is no different to Yammer whereby names of Private groups are visible unless the group is removed from the directory. To illustrate, with Report level filter applied:
And without:
The Power BI documentation describes the process through which you can validate the correct application of the Roles.
Assigning Users to Roles
You cannot assign users to a given role in Power BI Desktop. Assignment is achieved using the web version of Power BI. A word of warning: Prior to publishing the updated PBIX file in readiness to assign roles, it is wise to make a note of any existing Security options for the model in case they are overwritten! The PBIX file has to be published back into the App and allowed to overwrite the existing Report.
Whilst the PBIX file defines the Roles it does not describe the users who can use the Roles. Once the model is published back into the App you can add the users using the Security option for the dataset and then validate in a similar way to the Desktop app.
End result
Users who have a defined role are able to review the report in read only mode:
Users without a defined role are less fortunate:
The final step is to update the App with the revised dataset:
Footnote
When we move to using Office 365 Groups for group security I am hopeful that we will be able to switch our approach to one whereby we provide dynamic RLS access to the private Yammer data i.e. access can be based on whether the user is a member of the underlying Office 365 Group.
buildbod.com 