Updating Power BI Goals with Power Automate - A Practical Guide

Scorecards in Power BI have a predictable lifecycle. Someone senior asks for one. The BI team builds it. Everyone loves it at the launch meeting. Then, about six weeks later, half the goals still show last month's numbers because the people responsible for manual check-ins forgot, went on leave, or never really understood they were meant to be doing it.

That's the problem Power Automate solves here. Instead of relying on humans to remember to update goals, you let a flow do it on a schedule or when something happens in another system. Microsoft documents the basics in Update goals with Power Automate. I'll cover how we use it in practice, which patterns hold up, and where the sharp edges are.

A quick refresher on goals

Power BI goals (originally called metrics, which is why the docs URL still says "metrics") live on scorecards in the Power BI service. Each goal has a current value, a target, a status, an owner, a due date, and a history of check-ins. A check-in is a point-in-time record: a value, optionally a status, and optionally a note explaining what's going on.

Goal values can come from two places:

• Connected to data in a Power BI report, so the value updates when the underlying semantic model refreshes
• Manual, where someone types in a value and a note

Connected goals are great when the number already exists in a semantic model. But plenty of the goals that matter to a leadership team don't live in any model. Customer satisfaction scores from a survey tool. Headcount from an HR system nobody has connected to Power BI. Project milestones tracked in a SharePoint list. Safety incidents logged in a spreadsheet at each site.

Those are the goals that go stale, and they're the ones where Power Automate helps most. We've written previously about how scorecards and goals fit together if you want the bigger picture first.

What the Power BI connector gives you

Power Automate's Power BI connector includes actions for working with goals. The ones we use most are:

• Add a check-in to a goal, which records a new value, and optionally a note and status, for a given date
• Update a goal's status or other properties
• Get goals or goal details, useful when you need to read current values before deciding what to do

You identify the workspace, the scorecard and the goal, then pass in the values. The flow runs under the connection's identity, which matters more than people expect (more on that below).

There are also triggers related to goals, such as firing when a goal's status changes, which opens up the reverse direction: Power BI goals driving actions elsewhere.

Patterns that work well

1. Scheduled sync from a SharePoint list or Excel

This is the most common one we build. Site managers or team leads update a SharePoint list (or an Excel table in SharePoint) with their monthly numbers, which they're already comfortable doing. A scheduled flow runs each morning, reads the latest rows, and adds check-ins to the matching goals.

Why not just have them check in on the scorecard directly? Because they already have a process, and asking 30 site managers to learn a new screen is a bigger change management exercise than it sounds. Meeting people where they already work almost always gets better data quality.

A tip: put the goal ID in a column on the list, or keep a mapping table. Matching goals by name is fragile. Someone renames "Lost Time Injuries" to "LTIs" on the scorecard and the flow quietly stops working.

2. Event-driven updates from a line-of-business system

When a value changes in another system, update the goal straight away. For example, when a project in a project management tool moves to "Complete", a flow adds a check-in to the "Projects delivered this quarter" goal. Or when an HR system records a new starter, the headcount goal gets updated.

This works well when the source system has a decent Power Automate connector or can call a webhook. When it doesn't, you're back to scheduled polling, which is fine too.

3. Status changes that alert people

Going the other way: when a goal's status changes to "Behind" or "At risk", send a Teams message to the goal owner and their manager. Include the current value, the target and a link to the scorecard.

This is a simple flow and it makes scorecards far more useful. A scorecard that nobody opens until the monthly meeting is a reporting artefact. A scorecard that taps the right person on the shoulder when something slips is a management tool.

4. Automatic status rules with notes

Power BI has its own status rules, and they cover a lot. But sometimes the logic for "on track" is more complicated than the built-in rules handle, maybe it depends on data from two systems, or on the time of year. A flow can calculate the status and write it with a check-in note explaining why. Notes like "Auto-updated from survey platform, 412 responses this month" also help people trust the number.

The gotchas

This is where we've lost hours on past projects, so hopefully you won't.

The connection identity needs permission. The flow acts as whoever owns the Power BI connection. That account needs edit access to the scorecard and, for connected goals, appropriate access to the underlying data. If the flow is owned by a person and that person leaves, the flow breaks. We strongly recommend a dedicated service account for production flows, with flows owned by or shared with a team rather than an individual. Ask your licensing and security people what's acceptable in your tenant, because service accounts need their own Power BI licence.

Connected goals and manual check-ins don't mix cleanly. If a goal's value is connected to report data, writing a manual value from a flow will either conflict or get overwritten on the next refresh, depending on the setup. Decide per goal whether its value comes from a semantic model or from a flow, and stick with it. You can still use a flow to add notes or change status on a connected goal.

Dates matter. Check-ins are dated. If your flow runs at 1am UTC and you're in Brisbane, "today" in the flow isn't today in Brisbane. We've seen monthly values land on the last day of the previous month because of timezone conversion. Be explicit about the check-in date, and convert to Australian time zones where it matters.

Duplicate check-ins. A scheduled flow that runs daily and adds a check-in every time will fill a goal's history with identical entries. Either check whether the value has changed before writing, or only write when the source row has been modified since the last run.

Licensing. Goals and scorecards need Power BI Pro or Premium Per User for creators and editors, and viewers need appropriate access depending on whether the workspace is on capacity. Power Automate with standard connectors is included with most Microsoft 365 licences, but if your flow reaches into premium connectors (SQL, HTTP, many line-of-business systems), you'll need Power Automate Premium for the flow owner. Check this before you design, not after.

Error handling. Out of the box, a failed flow emails the owner. That's it. For anything people rely on, add a scope with a "run after failed" branch that posts to a team channel. Scorecards that silently stop updating are worse than having no automation, because people assume the numbers are current.

A worked example

Here's a flow we built for a client with about 20 retail sites.

Each store manager filled in a short Microsoft Form every Monday: weekly foot traffic, a customer satisfaction score from their in-store tablet survey, and any staff incidents. Responses landed in an Excel table.

A Power Automate flow triggered on each new form response, looked up the store's goal IDs in a SharePoint mapping list, and added check-ins to three goals on that store's sub-scorecard. It wrote a note with the manager's name and any comments they'd entered. If customer satisfaction dropped below the threshold, the flow also sent a Teams message to the regional manager.

Rollup goals at the regional and national level aggregated the store goals automatically.

Before this, a coordinator spent most of Monday chasing managers and typing numbers into a scorecard. After it, the scorecard was current by 10am every Monday, and the coordinator spent that time actually following up on the stores that were struggling. Total build time was a few days, most of which was agreeing on goal definitions with the business, not building the flow.

That's typical, by the way. The technical work in these projects is rarely the hard part. Agreeing what "on track" means is.

Is it worth it?

For scorecards with more than a handful of manual goals, yes. The flows are cheap to build and the payoff is a scorecard people trust because it's current.

Where I'd be cautious: don't build a fragile web of 40 flows to prop up a scorecard nobody looks at. If the meeting where the scorecard gets reviewed isn't happening, automation won't fix that. Sort out the management rhythm first, then automate the data entry.

Also keep in mind that Microsoft has been shifting investment towards Fabric and Copilot. Goals still work and are supported, but check the current documentation for any changes to the roadmap before you build anything large on top of them.

If you're looking at automating scorecards or other reporting processes, our Power Automate consultants do a lot of this kind of work, usually alongside our Power BI team. And if your reporting automation is starting to need judgement rather than just moving numbers around, that's usually the point where an AI agent starts to make more sense than another flow. Talk to us and we'll tell you honestly which one fits.