Power BI Goals Introduction, Part 3

by Treb Gatte


I’m encountering questions and confusion about Power BI Goals in my user group presentations. This post will address those questions so that you are clear on how to proceed with Power BI Goals.

If you are just hearing about Power BI Goals, check out https://marqueeinsights.com/power-bi-goals-introduction-part-1/ where we introduce the feature.

In Part 2, we go through an unboxing of the feature https://marqueeinsights.com/power-bi-goals-introduction-part-2/

Learn how to set up Power BI Goals

If you want to see the video of how to set up these three types of Goals, click the button below to have the link sent to you.

Power BI Goals Hierarchy Confusion

Power BI Goals enables you to present the status of a key outcome that can optionally be tied to data. Treating Power BI Goals as a glorified hierarchy of metrics may lead you to miss a more valuable use value of Goals.

Note, Goals do not roll up. The hierarchy is there to provide a context for the goal and subordinate goals. If you need data rollup, you may want to look at alternatives.

Part 4 of our blog series covers the ability to support OKRs (Objectives and Key Results) with Power BI Goals. OKRs are a very powerful mechanism for remote workers to stay in sync and focused on the most important work.

Goal Hierarchy

Power BI Goals enable you to capture up to five levels of hierarchy. The image below shows four levels in use.

One observation from meeting on the topic is that many people want different review cycles per level of hierarchy. In the example below, note:

  • Level 1 is an Annual goal
  • Level 2 is a Quarterly goal
  • Level 3 is a Regional goal
  • Level 4 is a Facility goal

This hierarchy example is one way that you can organize the goals but it is not the only way. We recommend that you account for goal duration in your Goal design. Currently, the only way to indicate the duration of the goal is with the Start and Due Date. While this data captures the time frame, it is not obvious to the user the time scope intent.

In our prototyping, we have adopted a naming strategy where the beginning of the goal indicates the organizational aspect. It’s not ideal but it’s simple, it works, and we can parse it out in the back-end reporting later.

Executive Summary Scoreboard example

Goal Types

Many seem confused by the types of Goals. Goals support three different configurations that impact how you capture the related data for Current and Target Values.

The different types change the behavior of the check-in. Manual Entry Goals require a check-in for updated information to be entered. Check-ins for data connected goals, on the other hand, enable you to update the status and add notes only. The data, as shown in the video, is automatically updated when the underlying linked source is updated.

Goals can be linked to report visuals in v2 workspaces, regardless if they are Pro or Premium workspaces.

Manual Entry

The simplest version of Goal Type is Manual Entry. This goal type enables you to manually track and provide status on a Goal. It has the advantage of being easy to implement which is especially attractive to organizations who are not clear yet on what they want to track. You decide your tracking cycle and then every day/week/month/quarter/year, you go to the scoreboard, find the goals you own, and do a check-in.

This Goal Type is the default when you create a new Goal. You fill in the Current and/or Target values when you create it. When you do a check-in, you are prompted to fill in the Current values and status value. You can also add a note if desired. With each entry, the graph will show the trend over the check-ins.

Goal using Manual Data check-in screen

Point in Time

This Goal Type enables you to tie a Goal to a single value. The check-in enables you to add notes and updated the status. When the underlying dataset refreshes, the linked visual updates and the updated data automatically appears in the linked Goal.

This can be especially useful in Goals where current state is all that matters. For example, the count of Net New Clients for the Goal timeframe supports this type of Goal. As you add new clients to the CRM system, the underlying connected model updates and updates the Goal Count as well.

Note in the image below that you cannot change the current value and that only the latest check-in has a current value.

Goal tied to a single data point check-in screen

Time Series

This Goal Type enables you to see the trend over time for a given Goal. It requires that the underlying data source supports data over time via the linked Power BI visual. The time series data can appear holistically in the goal if you take the default settings. When the underlying data refreshes, the goal will automatically update with this data.

Use the check-in to add notes and to update the status as needed.

In the image below, I use the Marquee Insights for Issue Analysis product for my data source. It brings in all the version updates from the Issue Tracker list that is part of SharePoint. I am interested to see how many New issues are being opened over time in this example. When the model refreshes, the Goal is updated, and the trend is extended.

Goal tied to a data series check-in screen

6 Responses to “Power BI Goals Introduction, Part 3”

July 16, 2021 at 12:08 am, Gabriel said:

good afternoon, i would like to know if it is possible to automate this process of goals, so that the end user of the report does not have to create these goals manually, but through selections in the bi or by powerapps


August 25, 2021 at 7:30 am, Treb Gatte said:

Hi Gabriel,

There are programmatic interfaces to do so. However, the documentation on how to do it hasn’t made it out the door yet. I’m looking forward to getting the Power Automate actions that were demonstrated at Microsoft Business Applications Summit.


August 17, 2021 at 2:46 am, Treb Gatte said:

It’s on the Power BI Roadmap so it’ll be available at some point in the future.


August 18, 2021 at 7:24 pm, Sam said:

I have a goal where I want to be “not more than” eg. the queue should be no longer than 40 at XX:XX time on each day. Is this currently possible?


August 19, 2021 at 1:42 am, Treb Gatte said:

I’m thinking you could do something like each queue item takes x time to address on average. The queue capacity is y. The Goal would then be to ensure available queue capacity is positive or zero. If it goes negative, then you have a real problem.

The time aspect is interesting. Essentially, you are decrementing the queue capacity as you get close to the time. All of these calculations would be done in the underlying model and reports that you then connect to actual and target.

I hope this helps.


August 25, 2021 at 6:11 am, Sam Gamble said:

Hey Treb
I think that’s a good way to get around it. I guess the point would be how many items do we have that are over X days for example.


Leave a Reply

Your email address will not be published. Required fields are marked *

The reCAPTCHA verification period has expired. Please reload the page.