Over the last few years, I’ve ended up building a surprising amount of reporting infrastructure.

I didn’t really plan for that to happen. The work just kept accumulating around recurring operational reporting. Every quarter there was another export process, another KPI review, another request to combine data from systems that weren’t designed to line up cleanly in the first place.

At first, I assumed most of the effort would happen inside Power BI itself.

Over time, the recurring friction kept showing up somewhere else entirely.

Quarter rollovers. Source replacement. Refresh failures. File paths are changing unexpectedly. Someone forgot which spreadsheet was supposed to remain untouched because the transformations were happening upstream in Query Editor instead.

The dashboards themselves were usually fine.

It was the maintenance surrounding them that kept becoming fragile.

The reporting volume grew gradually:
Highspot digital room analytics, support case reporting, Workday training completion tracking, quarterly operational summaries, subscription comparisons, and leadership KPI dashboards.

Individually, none of those workflows felt especially complicated.

Collectively, they started creating a surprising amount of operational overhead.

By that point, most of the work had already shifted upstream anyway. Folder structure. Naming conventions. Power Query transformations. Dynamic date handling. Refresh behavior. Trying to reduce the number of manual steps that depended too heavily on memory.

The visuals became one layer inside a much larger reporting process.

The Quarterly Maintenance Problem

One of the clearest examples was quarterly Highspot digital room reporting.

Originally, the process was extremely manual. Every quarter looked roughly the same.

Export the latest report from Highspot. Open the PBIX. Replace the previous quarter’s source file. Update quarter filters. Refresh the report. Fix whatever visual shifted unexpectedly. Double-check the quarter ordering. Publish again.

Technically, the workflow worked.

But it required remembering the process correctly every single quarter, which becomes less reliable once reporting starts competing with everything else happening during quarter close.

Eventually, I rebuilt the process around folder-based ingestion instead.

Instead of connecting Power BI to individual quarterly exports, the semantic model connected to a parent SharePoint folder:

/Highspot Reports

From there, Power Query filtered the relevant files, ignored archive content, standardized the exports, and automatically combined everything into a single dataset.

After that, the quarterly workflow became much smaller.

Export the report. Save the XLSX. Drop it into the correct folder.

The refreshes handled the rest.

What surprised me afterward was how much mental overhead disappeared once quarter rollover stopped being a recurring maintenance event. I wasn’t opening reports just to push filters forward another three months anymore.

I added calculated fields like:

• Quarter Number
• Quarter Index
• Year Quarter
• Year Quarter Sort

Mostly so the reports could determine the latest quarter automatically and rotate reporting windows forward without manual intervention.

At the time, that felt like a small cleanup improvement.

Six months later, it felt much bigger because the reports were still updating correctly without anybody touching the quarter visuals.

I also replaced several quarter-specific visuals with Small Multiples. Originally, there were separate visuals for Q1, Q2, Q3, and Q4, all with their own filters and formatting behavior. It worked, but maintaining them became tedious surprisingly fast.

One dynamic visual ended up being much easier to live with than four separate visuals that slowly drifted apart over time.

Most of the Fragility Lived in the Translation Layer

I ran into similar problems while building quarterly support case reporting that combined Salesforce support data with Sage Intacct subscription information.

The reporting itself wasn’t especially difficult.

The fragile part was ensuring product naming remained aligned across multiple systems that evolved independently.

If naming drifted even slightly, relationships broke silently. Metrics disappeared. Counts stopped matching. Sometimes a visual still rendered normally while showing incomplete data underneath.

That kind of issue is difficult because the report doesn’t necessarily look broken at first glance.

Honestly, a huge amount of reporting value ends up living in this normalization work.

Not really in the dashboard layer itself.

More in the translation layer that makes inconsistent operational data trustworthy enough to report on repeatedly.

Over time, I stopped manually cleaning exported spreadsheets almost entirely. The cleanup moved upstream into Power Query instead:
standardizing product names, removing totals rows, parsing quarter values, generating date fields, filtering archive content, and aligning inconsistent naming conventions that had accumulated over time.

One workflow explicitly depended on leaving exported Excel files untouched because all transformations were centralized in Query Editor instead.

That ended up making the process much easier to maintain later because the transformation logic stayed visible. Fewer manual edits introduced inconsistencies halfway through the reporting cycle.

It also reduced the amount of tribal knowledge sitting in somebody’s head.

Reducing Invisible Human Steps

Eventually, I added Power Automate to parts of the process, too.

The flows monitored SharePoint reporting folders, validated uploads, triggered refresh behavior, and sent Teams notifications when something failed unexpectedly.

I wasn’t really trying to automate everything.

Most of the improvements came from removing small, fragile steps that people inevitably forget during busy reporting cycles.

A surprising amount of reporting instability comes from things that seem minor at the time:
saving a file in the wrong location, refreshing the wrong dataset, updating the wrong quarter filter, or modifying a source export directly instead of letting Query Editor handle the transformation.

None of those problems is dramatic on its own.

But once reporting becomes a recurring operational infrastructure rather than a one-time analytics project, the accumulation becomes noticeable.

Especially when several reports all depend on similar maintenance habits staying consistent quarter after quarter.

What Leadership Usually Wanted

Another thing I learned pretty quickly is that leadership rarely wants raw exports; they just want confidence in the numbers. 

Trend visibility. Quarter-over-quarter movement. Clarity about what changed and whether the reporting process itself could be trusted.

That gradually changed how I approached the work.

I cared less about whether a dashboard looked impressive and more about whether the reporting process would break at 4:30pm on a Friday because someone skipped a maintenance step during quarter close.

The operational improvements in the Highspot reporting pipeline ended up eliminating:

• query replacement
• manual quarter shifting
• visual reconfiguration
• broken file path issues
• stale quarter reporting

Eventually, adding another quarter stopped feeling like a reporting event at all, which mattered more than most of the visual improvements I made during the same period.

The reporting systems that proved most useful weren’t necessarily the prettiest.

They were usually the systems that still made sense months later, when nobody fully remembered how the original process worked.