For many IT admins, troubleshooting a Power BI Report Server can be a daunting task. With so many potential sources of error and so much data to collect, it can be difficult to know where to start. Fortunately, the Power BI Report Server Troubleshooting Tool is here to help.
Think of this tool as a giant hammer in your toolbox, ready to take on any nail that needs to be driven down. The hammer I provide is certainly not the right tool for all issues with Power BI Report Server but, I hope you will be able to address many of the nails / issues needing to be fixed. To be clear “the tool is not fixing anything, it is just collecting data”. This troubleshooting tool is designed to make your life easier with automating a majority of the collection of data you would do either way. This data is coming from various sources, therefore might also give you an idea about things to investigate which you have previously not considered.
The best part? It’s incredibly easy to use. All you need to do is download the script and execute it on your report server machine. Assuming you have the “reportserver” database on your localhost, everything should work just fine. Even if that’s not the case you will either way get prompted for various variables you could modify or not.
One important caution to keep in mind is that the script is designed to collect everything. Depending on the number of log files and rows in your executionlog, it may take some time to finish. However, the good news is that all of the scripts included in the tool are a great starting point for troubleshooting a wide range of scenarios.
So, what exactly does this tool collect? Here’s a quick rundown of what you can expect to be collected:
Executionlog3 view: This view provides a wealth of information about the execution of your reports, including data about the report itself, the user who ran the report, and any errors or warnings that were encountered.
Event table: This table contains a detailed log of all the events that have occurred on your report server. Normally this table should be empty, if that’s not the case you have most likely an issue or at least a backlog most likely with refreshes/subscriptions.
ConfigurationInfo table: This table contains information about the configuration of your report server, including settings related to email delivery, security, and more.
Subscription and schedule refresh last status: This script collects data about the last status of your report subscriptions and schedule refreshes. This is incredibly helpful to identify if end users created a subscription potential harmful for your report server, either because of errors or because of potentially unnecessary frequent scheduling.
Subscription and Schedule Refresh History table: This table contains a log of all the subscription and schedule refreshes that have occurred on your report server, including information about when they occurred.
Rsreportserver.config file: This file contains configuration settings for your report server, including information about database connections, security settings, and more.
All “.Log” files, trace and dump files are excluded. Log files are capturing almost every traffic happening to your report server. In the biggest majority of the cases if you see an issue in Power BI Report Server you will find here more details about this. Since the log files are an unstructured log file, having a timestamp is essential.
Timestamp of error from user input: This allows you to focus on specific errors or issues that you have encountered and make sure you focus during your troubleshooting on the right issue.
While this collection of data is certainly comprehensive, it’s important to note that the script could be elaborated to further scenarios, such as troubleshooting Kerberos, SSRS, or performance issues. This is just the start of this tool and I looking forward if someone takes it further with a different hammer or makes this hammer even bigger.
In conclusion, the Power BI Report Server Troubleshooting Tool is a valuable addition to any IT professional or developer’s toolkit. It simplifies the process of collecting data and provides a great starting point for troubleshooting a wide range of scenarios. So why wait? Download the script and give it a try today.
As a support engineer, we often receive requests for usage, audit, or monitoring reports for Power BI Report Server. Sometimes, there are support requests, users could easily self-resolve themselves if they would just have the right tool. For Power BI Service there are audit and monitoring templates available, but for Power BI Report Server there is not much or at least to my knowledge nothing publicly available.
The first page is the most comprehensive one, with the highest information density, providing a report inventory and display for usage statistics at the same time. You could definitely consider separating the usage statistic from the report inventory.
Depending on the objective of analysis you have the option to switch the table with a bookmark navigation button to focus on users or reports.
This report page is also great to investigate the report which have rarely never or not lately been used. To define which unused reports you want to display I recommend to use the bottom right slicer. In case you have reports, which have never been open with an “interactive request” once, there is a separate slicer for this as well.
One main asset of the pbix is the following sql script for the purpose of building a catalog table. The sql script combines information from various tables into one catalog dimension for all of your items in your report and has the very most properties of each item.
2. Schedule Refresh and Subscription Overview
The second page is for subscription and schedule refresh already discussed in a previous article: Power BI Report Server Monitoring for Subscriptions and Schedule Refreshes. New here is on the bottom right corner the number of lines in the event table. The bigger the number the more likely you will be having an issue with a big backlog. Depending on the nodes you have this might take shorter or longer to catch up. In case you have not multiple nodes through scale-out deployment available, the server will be able to start 6 events (schedule refreshes or subscriptions) per minute.
3. General Config Information
The third page is nothing special, just some report server configurations, which you can easily see and adjust in the advanced properties of the report server.
More Info about the PBIX and how to get started.
All queries in the report use direct query mode, so there’s no need to refresh, and your monitoring is always up to date. To make the report work for you, replace the database parameter “ReportServer” with your database name. The report should be opened on your report server machine, since it is using server localhost. The report was created with Power BI Desktop for Report Server on Sep 22, so you should be able to use and publish it to your report server. Instead of a sql view in the database I chose to add the date dimension under utilizing the the system table “master..spt_values” starting from 2020 till the current date.
There are various documentations how to get an overview of subscription and schedule refreshes such as the following community discussions: info1, info2 , but Filipe Caetano made me aware of a script which is used for one of the two overview tables in the subscription/schedule refresh page
Taking the report further
I am sure the report still has a lot of potential. It could be enhanced further if the decision would be made to divert from direct query connection to import connection mode. This would enable to integrate data from various other sources, such as report server log files, the rsreportserver.config, powershell or WEB API calls.
Furthermore there is quite some potential to optimize the sql queries even further. For example one could merge the subscription/schedule refresh dimension with the catalog dimension.
For sure visualization and report design wise the report is definitely not where I would like to have it. for example this monitoring report is definitely not IBCS compliant, but I would be happy to see someone taking it in this direction further.
Ask for a Power BI Report Server Assessment
In case you want to know more about this topic, I highly recommend that you reach out to a Microsoft representative in your region, such as your Customer Success Account Manager, for assistance and ask for a Power BI Report Server Assessment or for a Power BI Service Assessment potentially available to you.
Please send me Feedback
If you found the pbix helpful or if you have any feedback I would be happy to hear about it. Feel free to ping me via the channel that suits youi.
Also if you are able to develop the pbix further, I would be super happy if you send me your version back.
This article heavily relies on the information of Michael Kovalsky’s blog article “Top 10 Power BI mistakes and their best practice solutions” published on his website elegantbi.com. The last three points are additions to Michael’s article, focused more on data model best practices, less focused on data model performance.
When working with Power BI, creating a well-performing data model is crucial for creating efficient and informative visuals. The performance of your data model can have a direct impact on the speed and responsiveness of your Power BI reports, and it is important to take steps to optimize your data model for the best possible performance.
Have only needed columns and tables in your data model. This will help to keep the data model lean and reduce the amount of data that needs to be processed. Unused columns and tables can slow down performance, and it is important to regularly review and remove any unnecessary columns or tables.
Use a clean star schema with one time dimension. A star schema is a type of database schema where a central fact table is connected to several dimension tables. This type of schema is well-suited to Power BI and can improve performance. The bare minimum for every data model is to have at least one date dimension, and almost every data model has somewhere a date column. In case you have multiple date columns in one fact table, such as order and ship date and therefore think you would need multiple date dimensions, I would still go with one date dimension and for such use cases add an inactive relationship in combination with DAX function USERELATIONSHIP for the measures which need the unusual date relationships.
Avoid bi-di or many-to-many relationships. These types of relationships can add complexity to your data model and slow down performance. Instead, use CROSSFILTER with IF to handle these types of relationships. CROSSFILTER can be used to control the direction of the relationship and can help to improve performance.
Move calculated columns and tables to the database, this can significantly improve the performance of your data model. By keeping calculations at the database level, you can offload computation from Power BI and take advantage of the processing power of your database engine.
Avoid transformations within the model. Adding unnecessary calculations, column creation, and data manipulation can slow down performance and make it harder to understand your data model. Keep your data model as simple as possible. and move all transformation back to your datawarehouse or if possible to the datasource. For example if you have a SQL database connecting to, than use a plain Select * From Table.
Yes “*” and not each column separately. This enables you to be fully flexible with the columns you add or modify in the backend.
Yes “Table” to improve perfromance further and not a SQL View. You can use a stored procedure to populate the table with the exact same logic you would have in the SQL View. This is important especially with direct query.
In DAX, avoid using “/”, SEARCH, IFERROR, CONTAINS, INTERSECT and FILTER, as these can slow down performance. Instead, use alternative functions that have better performance characteristics. Instead of “/” use DIVIDE. Sticking with the DIVIDE example, you can use the third condition in the filter statement instead of IFERROR and CALCULATE or CALCULATE + KEEPFILTERS instead of FILTER.
Use ‘Table’ prefix for calculated columns, not for measures, following a style guide can help keep your data model organized. By using a consistent naming convention, you can make it easier to understand and navigate your data model. Style Guide and adding the check for it in Tabular Editor if not already in Tabular Editors’s Best Practice Analyzer.
Calculated Column or Measure = ‘Table’[Column Name] or [Measure Name]
Reduce the number of measures in your data model by using calculation groups and visuals field parameters. Too many measures can slow down performance, and by reducing the number of measures, you can improve performance. But more importantly this will improve the datamodel’s usability as well. Calculation groups allow you to group similar calculations together or extend your data model with more measures, which otherwise would have to added manually as explicit measures. One calculation group which should exist in all data models is the Time Intelligence Calculation Group. You should be able to just copy paste the calculation group template if the names of your date column and date dimension match my template. Otherwise adjust the template and paste the tables afterwards into your model. Download the Time Intelligence Calculation Group Template here: https://github.com/KornAlexander/PBI-Tools/blob/main/Calculation%20Group%20Time%20Intelligence.bim
Add a last refresh time-stamp to your data model, this will help you keep track of when your data model was last updated. Please make sure to implement this per partition. This can be useful when troubleshooting performance issues, as it allows you to see when data was last updated.
Use empty measure tables, display folders and detailed row expressions to keep your data model organized and easy to understand. Empty measure tables allow you to organize your measures, while display folders allow you to group tables and columns together. In case you are using Analyze in Excel with your published model you will need to set up additional things:
Relationships need to manually recreated, with fictional columns having just one row. This is needed that the Excel report consumer will immediately know which relationships are possible if the empty measure table is selected. If you are using multiple fact tables, this will pose an issue, taking the maximum possible relationships will at least not hide possible attributes. This needs to be carefully managed, since you might show or hide possible relationships.
Detailed row expressions allow you to modify the details shown when you connect to your model in excel and apply a drillthrough with double click onto the value in your pivot table. If detailed rows expressions are not set for measures in an empty measure table than this drillthrough will show just the one fake row you have in your empty measure table.
By following these best practices, you can significantly improve the performance of your data model in Power BI or Excel, making it faster and more efficient for creating visuals and gaining insights from your data. It is always good to keep in mind that every dataset and every use case is unique and what works best for one dataset may not be the best solution for another. As you work with Power BI or Excel and your data model, it is important to regularly review and test your data model to ensure that it is performing as efficiently as possible.
It’s very important to keep in mind that best practices are general guidelines, but it’s important to test them and see how they work in your specific scenario and data model, as they may not always be the best solution in all situations.
As a Power BI Report Server Administrator, it is crucial to monitor the performance of your report server and keep track of your subscriptions and schedule refreshes. Inefficient utilization of report server capacity is a common issue, for instance, when there are specific periods of high server load and others with minimal activity. This can be a caused by schedule refreshes and subscriptions set up to be triggered all at the same time. This article explores how you can make use of a Power BI report, the job agent, and Power BI Report Server’s database table to visualize potential bottlenecks.
Thanks to Frederik Bogaerts, making me initially aware of this Power BI report and thanks to a blog post from Mattias de Smet, I was able to modify this Power BI report for monitoring not only the SQL Server Agent but also on a separate tab the Power BI Report Server. The main addition to Mattias’ report is that the main objective of my report is instead of monitoring only the SQL Server Agent I wanted to monitor the Power BI Report Server’s schedule refreshes and subscriptions as well. Nevertheless the pbix file and detailed description provided by Mattias was particularly helpful in getting started.
Inspiration for this report also came from Ganttchart’ paginated report blog post about “Visualizing Power BI Report Server Refresh Schedule”, which is particular good if the environment to monitor is a SQL Server Reporting Services and not a Power BI Report Server. This is due to the fact that Pedro’s WIP solution is a paginated report. Just like Pedro’s paginated report, also this solution is based on the dbo.SubscriptionHistory table.
Theoretically the SQL Server Agent could also be used to monitor the report server, with the exception that the report server’s jobs in the SQL Agent have a GUID, which need to matched with the report server’s database tables. Furthermore in my repro, the SQL agent cleared the history when modifying or deleting the schedule refreshes and the duration in seconds of the jobs were not captured.
This solution is work in progress and needs to be taken further for sure, not only by monitoring all jobs, PBIRS, SSAS, SSIS, but even more importantly with further analysis of the Power BI Report Server’s database tables, such as the ExecutionLog3 View. One additional requirement is that if you want to see jobs of all services in the report, you would need to run those on the same machine. If this is not the case, like in many environment, an ETL pipeline would need to be set up to consolidate the different services. I would be interested to see if someone can take this approach further.
There are quite a few further checks and Power BI Report Server Monitoring which could be included in this report.
Instructions How to Set Up the Report
Step 1: Download and Open the Power BI Desktop file on your Power BI Report Server and authenticate against your SQL Server.
Make sure to open the report on the report server machine, since it is using localhost to connect to your database.
Step 2: in Power Query –> Change “ReportServer” to match your database name
Go into PowerQuery and modify the SQL Statments to match the name of your report server database name. In my case the name is “Report Server”, you might have a different name of your database. Once you have changed this you should be done and good to go.
Optional: Step 3: Creating a SubscriptionsAndScheduleRefreshes VIEW Used in the following script and for PBIRS Monitoring
The following steps are optional and only need to be applied, in case you want to see your Power BI Report Server jobs from the SQL agent and not from the database, as well as SSAS or SSIS jobs potentially on your SQL Server Agent.
In this step, we will be creating a view called “SubscriptionsAndScheduleRefreshes” in the “ReportServer” database. This view will be used by the subsequent view “Job_Step_History_Analysis” and therefore needs to be created first.
/*CREATE Or ALTER View SubscriptionsAndScheduleRefreshes
This view selects the ReportID, ScheduleID as JobName, and Path columns from the dbo.ReportSchedule, dbo.Schedule, and dbo.[Catalog] tables.
The script uses the WITH (NOLOCK) hint which allows the query to read data from tables that are being used by other queries.
The script joins the tables on the ScheduleID, and ReportID columns respectively.*/
USE [ReportServer] --change this line to the report server database name
GO
Create OR ALTER View [SubscriptionsAndScheduleRefreshes]
AS
SELECT rs.ReportID
,REPLACE(REPLACE(s.ScheduleID , '{', ''), '}', '') COLLATE SQL_Latin1_General_CP1_CI_AS AS JobName
,cat.[Path]
FROM dbo.ReportSchedule rs WITH (NOLOCK)
INNER JOIN dbo.Schedule s WITH (NOLOCK) ON rs.ScheduleID = s.ScheduleID
INNER JOIN dbo.[Catalog] cat WITH (NOLOCK) ON rs.ReportID = cat.ItemID
The “WITH (NOLOCK)” statement is used to prevent the view from being locked while it is being queried.
Optional Step 4: Creating a View for “Job_Step_History_Analysis” for Analysis of SQL Agent
In this step, we will be creating a view called “job_step_history_analysis” in the “msdb” database. The view is made up of data pulled from multiple system tables such as “sysjobhistory”, “sysjobs”, “syscategories” and joined with the synonym “SubscriptionsAndScheduleRefreshes” created in step 2. It uses a common table expression called “job_history” to select various columns. The view then Selects from the “job_history” CTE to produce the final output.
USE [msdb]
GO
/****** Object: View [dbo].[job_step_history_analysis] Script Date: 1/20/2023 9:31:18 PM ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
/*Create or ALTER VIEW job_step_history_analysis
This view selects various columns from the sysjobhistory, sysjobs, syscategories, and SubscriptionsAndScheduleRefreshes tables. The script uses the Common Table Expression (WITH) to define the job_history table.
The script filters for enabled jobs and excludes steps with step_id = 0.
The script also calculates various duration statistics and calculates the percentage increase of each duration from the average. The script also selects the error message if the job outcome is 'Failed'.*/
CREATE OR ALTER VIEW [dbo].[job_step_history_analysis]
AS
WITH job_history AS
(SELECT SJ.[name] AS [Job],
SJH.step_name [Step],
SJH.step_id [Step Order],
C.[name] AS [Category],
msdb.dbo.agent_datetime(SJH.run_date, SJH.run_time) AS [Start Time],
CASE
WHEN SJH.run_status = 0 THEN 'Failed'
WHEN SJH.run_status = 1 THEN 'Succeeded'
WHEN SJH.run_status = 2 THEN 'Retry'
WHEN SJH.run_status = 3 THEN 'Cancelled'
ELSE 'Unknown'
END [Job Outcome],
SJH.run_duration % 100 -- seconds
+(SJH.run_duration / 100) % 100 * 60 -- minutes to seconds
+(SJH.run_duration / 10000) % 100 * 60 * 60 -- hours to seconds
AS [Duration In Seconds],
IIF(SJH.run_status = 0, SJH.[message], '') AS [Error Message], --select error message if job failed
S.[Path]
FROM [msdb].[dbo].[sysjobhistory] SJH
JOIN [msdb].[dbo].[sysjobs] SJ ON SJH.job_id = SJ.job_id
INNER JOIN [msdb].[dbo].[syscategories] C ON SJ.category_id = C.category_id
JOIN [ReportServer].[dbo].[SubscriptionsAndScheduleRefreshes] S ON SJ.[name] = S.[JobName]
WHERE SJ.enabled = 1 --filter for enabled jobs
AND step_id <> 0 --exclude steps with step_id = 0
--AND SJH.run_duration > 0 --jobs with less than a second are not disabled
)
SELECT [Category],
[Job],
[Step],
[Step Order],
[Start Time],
[Job Outcome],
[Duration In Seconds],
MIN(job_history.[Duration In Seconds]) OVER (PARTITION BY Job, Step) AS [Min Duration In Seconds],
MAX(job_history.[Duration In Seconds]) OVER (PARTITION BY Job, Step) AS [Max Duration In Seconds],
AVG(job_history.[Duration In Seconds]) OVER (PARTITION BY Job, Step) AS [Average Duration In Seconds],
Case When job_history.[Duration In Seconds] = 0 THEN NULL
Else ((1.0 * [Duration In Seconds] / (AVG(job_history.[Duration In Seconds]) OVER (PARTITION BY Job, Step))) - 1) END As [Pct Increase],
[Error Message],
[Path]
FROM job_history;
GO
The following is only informational: The following select statement is already automatically included in the Power BI report, therefore it is not needed to actually execute this select statement. I found it helpful for troubleshooting and therefore am including it here. I also included a Where statement to filter out for the jobs of the Power BI Report Server, so in case you are looking for SQL agents jobs from Power BI Report Server you won’t find them, but you already should have them from the historysubscription table.
This SELECT statement selects various columns from the “job_step_history_analysis” view created in step 3. Additionally, the script applies several IIF and CONVERT functions to the “Min Duration In Seconds”, “Max Duration In Seconds” and “Average Duration In Seconds” columns to convert their values from seconds to a more human-readable format (hours, minutes, seconds). These converted columns are named as “Min Duration”, “Max Duration” and “Average Duration” respectively.
/* Documentation: This select statement selects various columns from the job_step_history_analysis view
and formats the duration columns to be in Hours, Minutes, and Seconds.
It also selects the Pct Increase, Error Message, and Path columns from the view.*/
SELECT
[Category],
[Job],
[Step],
[Step Order],
[Start Time],
[Job Outcome],
[Duration In Seconds],
[Min Duration In Seconds],
[Max Duration In Seconds],
[Average Duration In Seconds],
IIF([Min Duration In Seconds]/60/60>0,
CONVERT(VARCHAR, [Min Duration In Seconds]/60/60) + ' Hours ','') +
IIF([Min Duration In Seconds]/60> 0,
CONVERT(VARCHAR, [Min Duration In Seconds]%3600/60) + ' Minutes ','') +
CONVERT(VARCHAR, [Min Duration In Seconds]%60) + ' Seconds' AS [Min Duration],
IIF([Max Duration In Seconds]/60/60>0,
CONVERT(VARCHAR, [Max Duration In Seconds]/60/60) + ' Hours ','') +
IIF([Max Duration In Seconds]/60> 0,
CONVERT(VARCHAR, [Max Duration In Seconds]%3600/60) + ' Minutes ','') +
CONVERT(VARCHAR, [Max Duration In Seconds]%60) + ' Seconds' AS [Max Duration],
IIF([Average Duration In Seconds]/60/60>0,
CONVERT(VARCHAR, [Average Duration In Seconds]/60/60) + ' Hours ','') +
IIF([Average Duration In Seconds]/60> 0,
CONVERT(VARCHAR, [Average Duration In Seconds]%3600/60) + ' Minutes ','') +
CONVERT(VARCHAR, [Average Duration In Seconds]%60) + ' Seconds' AS [Average Duration],
[Pct Increase],
[Error Message],
[Path]
FROM job_step_history_analysis
Where [Category] <> 'Report Server'
Power BI is a powerful tool for creating visually engaging and actionable reports, and in my opinion it is also the best tool to apply IBCS to its fullest potential. In case you would not know IBCS is a set of guidelines for creating effective and actionable reports that provide clear and actionable insights. If not check out my previous post. Power BI has many built-in features that can be used to achieve compliance with IBCS, and in this post, we will explore some ways to do so.
The first step to achieving IBCS with Power BI is to ensure that your data model is well-structured and organized. This means creating a clean and simple data model with a clear and consistent naming convention. Once your data model is organized, it is important to focus on creating clear and consistent visuals. Power BI has a wide range of visualizations that could be tailored to suit the specific needs of your report, but to start off with IBCS, one should focus on just two types of visuals and forget the rest:
For categories: built-in table visual
For time: line or column chart visuals
IBCS with Power BI’s Built-In visuals
For an analysis with a focus on categories, you can use the table visual with conditional formatting. If needed, the bar and number can be split into multiple columns with a duplication of the measure just on this report not on the whole datamodel itself. Unlike the example below this would than allow that the bars don’t overlap the datalabel. Header and footer can be switched of and make both columns seem like one. As shown in both tables in the example below, the conditional formatting for bars on the table for each column will eventually create a multi-tier bar chart. This shows that once conditional formatting is applied, a table is not too far off from a bar chart.
For an analysis with a focus on time, you can use two or three visuals and make it seem like it is one visual. For the deviations chart make sure the axis font color is white. This is better than disabling the x-axis as a whole, to make sure the chart with actuals and the chart with deltas is equally spaced. This will create a multi-tier column chart, with two or three layers. Using this approach makes it easy to compare different measures over time.
Example of IBCS with Power BI’s built-in visuals:
It’s important to note that the table visual and line or column charts are not the only way to achieve IBCS compliance, and it’s important to test and try different visualizations, while following the IBCS guidelines and best practices to see which one works best for your data, and the story you want to tell with your report.
2. Design your Own Visual
Another way to achieve IBCS with Power BI is by creating your own visuals using Charticulator, which is now a community version created by Ilfat Galiev. Charticulator allows you to create customized visuals that can be tailored to suit the specific needs of your report. There is also a great IBCS tutorial on this by Curbal, which can guide you on how to use Charticulator to create IBCS compliant visuals. Curbalscharticulator IBCS tutorial
Finally, you can use external IBCS Custom Visual Providers such as, Zebra BI, xViz Variance Chart / Inforiver, TrueChart4PowerBI, Graphomate, 3agsystems and many other. These providers offer a wide range of custom visuals that can be used to create clear and engaging reports. Each one of these custom visuals has a different set of features and functionality that can be used to create different types of reports.
Zebra BI is great if your focus is financial and business reporting, but also has proven success other areas. Most likely Zebra BI is the leader in this market segment. In my opinion the main differentiator to the other IBCS custom visuals is that even if report authors are unaware of IBCS, the compliance with IBCS will still be at a very high level. This is due to a strategy to have a clear differentiation between three custom visuals: charts, tables and card. To have additionally the option for small multiples or tables with a deep hierarchy at a blazing fast speed is also a differentiator. By default there is less customization and user input needed to achieve a high IBCS compliance just drop in your main measures and you are done. Lately Zebra BI has deployed also an Excel add in, to ensure consistency across platforms. This is a move back to the roots, coming originally from an Excel add in background. There was also a PowerPoint add in launched, almost at the same time with Power BI enabling this functionality with their storytelling capabilities. The following shows an example of a Power BI “Finance-App” with the current selection being the income statement.
xViz Variance Chart is a custom visual that allows you to compare two measures over time. It has a feature called ‘variance analysis’ that can identify the difference between two measures and can be used to create variance charts. This visual was now integrated into the IBCS and Microsoft certified Inforiver Visual. Inforiver enabling with another custom visual also write back functionality is a key differentiator to enable data modification of Budgeting or Forecasting use cases. If planning capabilities should be in Power BI or rather on a backend system is another topic for itself. One additional strength of this custom visual is that xViz has a whole suite of various other custom visuals, not considered or necessarily recommended under IBCS.
TrueChart4PowerBI is a set of custom visuals that are designed to create charts that are IBCS compliant as well. It includes a variety of chart types such as column, line, and area charts and has a feature that allows you to format your charts to adhere to the IBCS standard. TrueChart decided to have just one custom visual for all use cases, no matter if you want to do an analysis over time or categories or both.
One key differentiators is that commenting can be done in the report itself. This is crucial since it makes it easy to apply important “message” part of IBCS and therefore ensures that actual insights will be created and not just sticking with awesome visualizations. The visualization by itself is not a story.
Also TrueChart is a product from and by the company HICO Group / HighCoordination GmbH. This is a huge advantage since unlike its competitors e.g. Zebra BI or Inforiver they have numerous IBCS certified German native speaking consultants. So in case you don’t already have a companywide full “buy-in” for IBCS ensuring a successful adoption through additional external help is key.
One additional good thing is that TrueChart is also available for QlikView / QlikSense. So if you are coming from a hybrid environment in that area and want to ensure a smooth migration from Qlik to Power BI than TrueChart is definitely worth considering.
Graphomate is also a great custom visual when it comes to IBCS implementation. Just like Zebra BI Graphomate also follows the approach to offer multiple custom visuals depending on the use case, such as: charts, matrix, bubbles, pictograms, tiles. In addition to offering a highly customizable custom visual, one key differentiator is that Graphomate is also available for SAP and Tableau. So if you are having a hybrid environment with those tools, than this is custom visual is definitely worth considering. One strength as shown in the picture below is that it can have various scenarios in one visual, such as actual, forecast and than switching to plan. The definition of outlier detection is definitely also not something I have seen with other providers.
3agsystems’ custom visuals focus is also definitely IBCS. To come straight to the point the main strength of this custom visuals is that it is free. It might not have the power of the other mentioned custom visuals but it is still very close to the IBCS standards and also integrates the multiple deviation tiers into one visuals. One thing which is special is that line, column and small multiple are separate visuals. Other IBCS custom visual providers have decided to make this one visual, because those visuals are serving all the same purpose of an analysis over time. Furthermore, to confuse a bit even more 3agsystems’ custom visuals are split depending on whether you need an absolute or relative variance. The other custom visuals have the option to have absolute and percentage deviation in one chart as multiple tiers.
In conclusion, each one of these custom visuals provides different set of features and capabilities and you should evaluate them based on the specific needs of your report and use case. Keep in mind that this is not a comprehensive list and there might be other custom visuals with a focus on IBCS available for Power BI.
Business Intelligence (BI) is a powerful instrument that can help organizations make better decisions and improve the company’s performance. However, very often I encounter poor BI reports with little to no insight. The assumption in this article is that poor reporting does not stem from an intent to deceive or misinform the report’s target audience. Instead, it is usually due to a lack of understanding about how to create effective and actionable reports.
Someone may argue that there are numerous ways to interpret and display the same data through visualizations, however I disagree. I believe that there is a single most valuable insight and one best way to visualize that insight. While a company’s objectives and strategies may impact the relative significance of certain key performance indicators or categories, it does not alter the effect that these KPIs or categories have on each other.
IBCS are a set of guidelines for creating effective and actionable reports. It provides a consistent and standardized approach to creating and presenting data, making it easier to understand and use. By following these over 100 rules, you can create reports that are easy to understand and provide clear insights. This will help to ensure that your reports are being used to drive decision-making and improve the company’s performance, rather than just being ignored. IBCS has proven its importance in everyday business already several times but also in a study conducted by blueforte at the Technischen Universität München (TUM) resulting in 61% less mistakes and being 46% faster when consuming reports. Management Summary
One of the key principles of IBCS is the use of a clear and consistent visual structure. This means that all elements of a report should be arranged in a logical and consistent manner, making it easy to understand and navigate. Additionally, IBCS emphasizes the use of clear and concise language, avoiding technical jargon and confusing terminology.
Another important aspect of actionable reporting is the use of the right visualizations. Choosing the right visualization for the data you are presenting is crucial for providing clear insights. For example, a line chart is a good choice for showing trends over time, while a bar chart is better for comparing values. IBCS provides guidelines for choosing the right visualization for different types of data.
To be even more precise the above mentioned rules are categorized into seven areas with the acronym SUCCESS to better memorize them. Putting the SUCCESS areas into a logical order:
I: Conceptual rules are guidelines that help to effectively communicate a message by using an appropriate narrative structure. They include:
Say: Convey the main message first and foremost.
Structure: Structure the information in a logical and coherent manner.
II: Perceptual rules are guidelines that help to effectively communicate a message through visual design. They include:
Express: Expressing the message through the use of appropriate visual elements. In very short there are two chart types covering the very biggest majority of the needs: multi-tier bar chart (table) for categories, multi-tier column chart for time. The combination of both should be than a small multiple multi-tier column chart or less often a multi-tier bar chart (table) with multiple previous period comparisons.
Simplify: Simplify the design to minimizing distractions and therefore avoid any unnecessary noise.
Condense: Once there is more space, the report author has the possibility to increase information density with adding additional elements. Condensing therefore means to utilize the limited space as effective as possible.
Check: Once more elements or charts are added, it is crucial to maintain visual integrity. In very short: “things which mean the same should look the same”. Among many other tasks, one is to check the scaling of the newly added visual elements.
III: Semantic rules are guidelines that help to effectively communicate a message through the use of a uniform notation system. This includes:
Unify: Unify all the above in a consistent manner and apply notation standards, such as through a notation manual or guide.
The very first area “Say” I would like to highlight specifically. Brent Dykes has published two great articles stating that one should not simply focus on the visualization part and also put a focus on the equally important data (analysis) and narrative (message) part. Elephant In The Room: Data Storytelling Is More Than Just Data Visualization
But in my opinion the focus on great visualization first is correct. Because like Brent correctly states in his “Insight Funnel” the dashboard/report is the frame for the analysis and consequent message which follows. Why Data Storytelling Requires a Mindset Shift
Yes you can convey a good insight with a pie chart if your analysis through other means and the message is the bomb. However my argument would be that you are much more efficient and effective with analysis and storytelling and the related message creation process if your storyframing / dashboarding is superb.
In conclusion, actionable reporting is essential for creating effective BI reports that provide clear and actionable insights. By following the guidelines provided by IBCS, you can ensure that your reports are easy to understand and provide the information that is needed to drive decision-making and improve performance.
Business intelligence will only reach its full potential if the concept of actionable reporting is applied, and IBCS is perfectly suited to help you do just that.