Custom Statuses in Power BI Goals - Making Scorecards Say What You Mean

The default statuses in Power BI scorecards are fine for a demo. On track, at risk, behind, overdue, completed, not started. Every organisation recognises them. But once you put a scorecard in front of an actual executive team, someone always asks a question the defaults can't answer. "What about goals we've paused?" "Where do we put the one waiting on the board decision?" "Is 'at risk' the same as 'needs attention'? Because they mean different things to us."

That's where custom statuses come in. Power BI lets scorecard owners create their own status values, with their own names and colours, so the scorecard reflects how your organisation actually talks about progress. Microsoft's guide on creating custom statuses walks through the setup. I want to talk about the design side, because that's where most scorecards go wrong.

A quick refresher on goals and scorecards

Power BI goals (Microsoft now generally calls them metrics) live inside scorecards. Each goal has a current value, a target, an owner and a status. Values can be connected to data in your Power BI reports, so they update automatically, or entered manually. Statuses can be set manually or driven by rules, for example "if current value is less than 80% of target, set status to behind."

Scorecards are aimed at the leadership and team-level view. They're not trying to replace your detailed reports. They're the page a GM looks at on Monday morning to see what needs their attention.

How custom statuses work

In the scorecard settings you can add new statuses alongside the built-in ones. Each custom status gets a name and a colour. Once created, it's available to set on any goal in that scorecard, either manually during a check-in or automatically through status rules.

A few things worth knowing:

• Custom statuses are defined per scorecard. They don't automatically carry across to other scorecards, so if you want consistency across a division you'll need to set them up in each one.
• You can use them in status rules, so automated logic can assign your custom values.
• They show up in filters and in the scorecard visual, so users can filter to "everything on hold" for example.
• You need edit permissions on the scorecard to create them.

The setup itself takes a couple of minutes. The thinking beforehand should take longer.

Design your statuses before you build them

Here's the mistake we see most. Someone gets access to custom statuses and creates eleven of them. "Slightly behind." "Very behind." "Behind but recovering." "Under review." "Pending finance." Within a month nobody knows which one to pick, so everyone picks whatever looks least alarming, and the scorecard stops meaning anything.

Fewer is better. In our experience five to seven statuses total, including defaults you keep, is the sweet spot. Each one should answer a single question for the person reading the scorecard: "Do I need to do something about this?"

A set we've used successfully with a few clients:

• On track - no action needed
• Watch - drifting, owner is aware and managing it
• Off track - needs leadership attention or a decision
• Blocked - can't progress without something external, such as funding, a dependency or a vendor
• On hold - deliberately paused, not failing
• Complete

"Blocked" and "On hold" are the two custom statuses we add most often. The defaults lump paused or blocked goals in with failing ones, and that distorts the picture. A goal the board deliberately deferred shouldn't show as red next to one that's genuinely going backwards. Executives read red as "problem." If half the red is actually "we decided to wait," they stop trusting the colour.

Colour is doing more work than you think

People read scorecards by colour first and text second. Probably 80% of the attention goes on the colour. So:

Keep red meaning one thing. Use it only for statuses that require action. If you give "Blocked" and "Off track" the same red, someone will ask why the blocked items haven't been fixed, when the owner can't fix them.

Grey for paused. Neutral colours for things that aren't being actively worked. It visually removes them from the "worry about this" pile.

Think about colour blindness. About one in twelve men has some form of colour vision deficiency. Red and green side by side is the classic problem. Status names are visible, which helps, but pick colours with decent contrast against each other, not just different hues.

Match your organisation's existing conventions. If your board pack uses amber for "watch," use amber. Don't invent a new colour language.

Rules versus manual statuses

Status rules are one of the better parts of Power BI goals. You define conditions based on the current value, target, dates or percentages, and the status updates automatically. Custom statuses work in rules too.

My honest view: automate the measurable stuff, keep judgement calls manual. "Off track" based on being more than 15% below target is a good rule. "Blocked" generally isn't, because no data point tells you a goal is waiting on a supplier. That needs a person to set it, ideally with a note explaining why.

One thing to be careful of: if a rule sets a status automatically and someone also sets it manually, make sure your team understands which one wins and when the rule re-evaluates. We've seen confusion where an owner set a goal to "On hold," and a rule flipped it back to "Off track" on the next data refresh. Test your rules against your custom statuses before go-live.

What's still rough

I'll be straight about the limitations.

Per-scorecard setup is tedious at scale. If you're rolling out twenty scorecards across an organisation and want consistent statuses, you're configuring them twenty times. It's not difficult, just repetitive, and it leaves room for drift where one scorecard ends up with "Watch" and another with "Watching."

Reporting across scorecards takes work. If you want an organisation-wide rollup of how many goals are blocked, you'll likely need to pull scorecard data into a semantic model and build it yourself. Doable, but not out of the box.

Scorecards themselves have had an uncertain feel. Microsoft has shifted naming and focus around goals and metrics a couple of times, and some organisations are hesitant to bet heavily on them. My view is they're useful for leadership-level tracking right now. Just don't build your whole performance management process on them without a fallback plan.

A practical rollout approach

When we help clients set up scorecards, the custom status work usually looks like this:

1. Run a 30-minute session with the leadership team. Ask what decisions they make from a status report. Design statuses around those decisions.
2. Write one sentence per status defining when to use it. Put it in the scorecard description or a linked page.
3. Pick colours with the rules above.
4. Configure the statuses, then build status rules for anything measurable.
5. Run two check-in cycles, then review. Are people using the statuses as intended? Is anything sitting in the wrong bucket?
6. Once settled, replicate across other scorecards and document the standard.

Step one is the one that matters. A scorecard is a communication tool. If the statuses don't match how leadership thinks about progress, it becomes a box-ticking exercise that someone updates on Friday afternoon and nobody reads.

Where this connects to broader BI work

Scorecards work best when they sit on top of a decent data foundation. If goal values are typed in manually every week, people stop updating them. If they're connected to well-built semantic models, the scorecard mostly maintains itself and the check-in becomes about the commentary and the status, which is where the human judgement belongs.

That's the bit we spend most of our time on with clients: getting the data model right so scorecards, reports and increasingly AI-driven insights all draw from the same trusted numbers. If you're working on that, our Power BI consultants can help, and we also do a lot of work on AI for business intelligence, where things like automated status commentary are starting to become practical. For organisations still working out what to track in the first place, our AI strategy engagements often start with exactly that question.

The short version

Custom statuses take two minutes to configure and are worth a lot more thought than that. Keep the list short, make each status map to a decision, keep red for things that need action, and separate "paused" and "blocked" from "failing." Get that right and your scorecard tells leadership what they actually need to know. Get it wrong and you've built a very colourful page that everyone has learned to ignore.