Power BI Goals and Scorecards - Setup, Licensing and Gotchas

Every executive team we have worked with has a slide somewhere that says "we are tracking these twelve things". The slide is usually a month out of date, the numbers were pasted in by hand, and nobody can say who owns the target. Power BI goals and scorecards are Microsoft's attempt to put those metrics in one place, connected to real data, with a named person responsible for each one.

We have been setting them up for clients over the last while, and the feature is more useful than it first looks. It is also more fiddly than the demo suggests. If you are about to roll it out across a business, the licensing and refresh details are where most of the surprises sit.

What goals and scorecards are

A goal in Power BI is a metric with a current value, a final target, and an optional trend. You can connect it to a data point in a semantic model, so the value updates as the model refreshes, or you can enter it manually and do check-ins over time. A scorecard is a collection of goals, usually grouped by team, initiative, or executive area.

The Scorecards hub in the Power BI service gives you a Recommended section that surfaces goals you are assigned to, goals you have edited, or goals you have checked in recently. Below that you get tabs for Recent, Favourites, Shared with me, and All scorecards. For most people, the Recommended section is the one they will actually look at, which is why the feature has real potential to change meeting habits.

The bit we like most is the check-in. Each goal can carry a history and a comment trail, so the owner can explain why a number moved. That is the part that turns a dashboard into a management conversation. Numbers without context get ignored. Numbers with a short note from the person accountable get discussed.

Licensing is the first thing to check

Here is the table that matters, as Microsoft currently lists it:

• Authoring and sharing scorecards, setting up goals, and performing check-ins requires a Power BI Pro licence.
• Viewing scorecards and goals requires either Premium capacity, or Fabric F64 or greater, plus a Free user, or a Pro licence.
• Viewing scorecard samples and authoring scorecards in My Workspace is available to Free users.

The practical consequence is this. If you have a team of 40 people who need to check in on goals, every one of them needs a Pro licence. If you have 400 people who just need to view the scorecards, you need either the capacity or a Pro licence for each viewer, and the capacity route is usually cheaper at that scale. We see clients get this wrong when they assume the Free user can contribute. They cannot. The Free user can look, but not update.

Before anyone builds a scorecard, check with your Power BI administrator which capacity your workspace is on. Goals that exist in a workspace on the wrong capacity can behave unpredictably for viewers, and fixing that after the fact is tedious.

Manual goals are not a live dashboard

This is the trap we see most often. Someone creates a goal, types in a current value, and assumes it will update over time like a connected metric. It will not. Manual goals are not connected to a data source with a scheduled refresh, so they only move when someone does a check-in.

That is fine if you want a commitment tracker, where the owner updates progress every fortnight and the team talks about it. It is not fine if you expected a live KPI. Make the distinction explicit when you train people. We now ask every client to decide, for each goal, whether it is connected or manual, and to name the check-in cadence for the manual ones.

For connected goals, the value only updates as often as the semantic model refreshes. If your model has no scheduled refresh, the goal will look frozen even though the underlying data is changing. Power BI supports import, live connection, and DirectQuery for this purpose, but whichever you choose, the refresh schedule is the thing to confirm. We have seen a finance scorecard show a six-week-old revenue figure for a month before anyone noticed, because the model was refreshed manually by someone who then went on leave.

Goal history is also tied to the shape of the date you connect. Power BI pulls history for time series data, but only when the connection includes a full date such as day, month and year. A connection based only on the month name or day of the week will not build a history. If you need trends, make sure the date field is a proper date, and tick the option to track all data in the time series when you connect.

Snapshots are taken at most once a day, and Power BI always keeps the last value for the day. That is fine for most executive scorecards. It is not fine if someone wants intraday movement. Set expectations early.

Permissions are layered

Goals sit on top of workspace permissions, and there are a few separate things to get right.

To create a scorecard in a workspace, you need the Contributor or Owner role there. If you see a yellow warning icon when you try to connect a goal to a report, check that you have build permission on that report. If you share a scorecard, the recipients need edit permission on it to add check-ins.

Then there are goal-level permissions. Workspace roles give view or build access to the workspace, but goal-level permissions can restrict who sees specific goals and who can check in on them. This is useful for a scorecard that spans a CEO's priorities and a specific divisional head's targets, where you do not want every reader to see every number. It is also the source of most "I can't see the goal my colleague mentioned" conversations, so document who has access to what.

The limits that will shape your design

The documentation lists several limitations. These are the ones that change design decisions.

Goals do not support row-level security. If you have RLS on your semantic model to restrict regional managers to their own data, a goal built from that model will not respect the restriction in the way you might expect. Plan your scorecard around that before you start, not after a regional manager asks why they can see the national number.

A single scorecard can hold up to 1,000 goals, and subgoals can go four levels deep. In practice, nobody needs anything close to 1,000 goals on one scorecard. If you find yourself building a scorecard with 200 goals, the scorecard is probably trying to do the job of three separate ones.

Goals do not support bring your own key, publish-to-web, or the SharePoint embed of the scorecard visual. Business-to-business sharing across tenants is not supported, and scorecards are not available in Multi-Geo capacities or in embedded analytics. If your business shares content with a partner firm on another tenant, check this early, because it is a common blocker.

Where we think it earns its keep

We have seen the feature work best in two situations. The first is a leadership team that already reviews a set of numbers every week. Moving those numbers into a scorecard, with a named owner and a short check-in note for each, usually improves the quality of the conversation within a month. People start arriving with the context already written down.

The second is an operations team with a clear target and a connected source. A distribution business we worked with had on-time delivery, damage rate and cost per order as connected goals, each tied to a daily refreshed model. The operations manager had a single place to check, and the head office stopped asking for the Monday email. That is the outcome you want.

Where it struggles is with strategic initiatives that do not have a clean number. "Improve customer sentiment" is not a goal you can connect to anything. You can still track it manually, but at that point you are using a scorecard as a project tracker, and a project tool such as Planner or Jira may serve you better.

A quick rollout plan

If you are planning to introduce goals across the business, we suggest this order:

1. Pick two or three scorecards that already exist as slides or spreadsheets. Do not start from scratch.
2. Decide for each goal whether it is connected or manual, and document the check-in cadence for the manual ones.
3. Confirm the semantic model has a scheduled refresh and that the date fields are proper dates.
4. Check licences for the authors and the viewers, and confirm the capacity your workspace sits on.
5. Set goal-level permissions only where you have a real confidentiality need. Do not lock everything down by default, or nobody will look at it.
6. Run one monthly check-in cycle before you roll out more widely. The first cycle will reveal the gaps.

If you want a hand with the model side or with the licensing conversation, our Power BI consultants work through this regularly with Australian organisations. Where scorecards sit on top of a broader Fabric estate, our Microsoft Fabric consultants can help with the data foundations. And if the real question is how to get better decisions out of the data you already have, our AI for business intelligence page covers how we approach that more broadly.

Our view is simple. Goals and scorecards are worth using, particularly for leadership reviews and operations targets with a clean data source. Treat them as a conversation tool, keep the connected and manual goals clearly separated, and check the licensing before anyone announces a rollout.

Reference: Get started with goals in Power BI (Microsoft Learn)