Which transformations should stay in Power Query?
← All services
Power Query Cleanup
Does every source change create another Power Query problem?
A practical review of Power Query logic, resilience and maintainability — including the boundary between source, transformation layer and semantic model.
DOES THIS SOUND FAMILIAR?
Start with what is actually happening.
- Queries contain dozens of steps that are hard to follow.
- Folder combinations break when a column changes.
- The same transformations appear in multiple queries.
- Refresh times keep increasing.
- Nobody is sure whether transformations are still folding.
WHAT WE NEED TO ANSWER
Good work starts with better questions.
Which should move upstream?
Where is logic unnecessarily repeated?
How can the queries become more resilient to schema changes?
WHAT I REVIEW
The scope follows the problem.
I do not force every engagement through the same checklist. These are the areas that may matter; the agreed scope determines how deep we go.
Query structure and dependencies
Query folding
Combine Files patterns
Schema drift and resilient column handling
Data types and transformation order
Repeated logic and staging queries
Parameters and environment-specific logic
Refresh implications and source-side opportunities
WHAT YOU GET
Something you can use after the conversation ends.
The output should help you make a decision, change a practice or move the work forward. It should not exist simply to prove that work happened.
Query Review
A clear view of the main complexity, resilience and performance issues.
Resilience Recommendations
Practical changes for handling common source and schema changes more safely.
Simplification Opportunities
What can be consolidated, parameterised or moved upstream.
Refactoring Example
A concrete example where seeing the improved pattern is more useful than reading about it.
Layering Guidance
A clearer answer to what belongs in the source, Power Query and the model.
HOW IT WORKS
Enough structure to make the work clear. Not so much process that the process becomes the work.
Context
We start with a short conversation about what is happening, what matters and what has already been tried.
Review
I analyse the relevant parts of the solution or operating model at the depth agreed for the engagement.
Prioritise
I organise observations around impact, risk and usefulness — not around how many issues I can find.
Walkthrough
We go through the findings together, challenge assumptions and discuss trade-offs.
Next step
You decide what happens next: implement internally, continue together or stop because the focused engagement was enough.
YOUR TIME COMMITMENT
I keep the client-side time demand deliberately light. A focused assessment usually needs a kickoff conversation, access or materials, and a final review session. We agree the exact involvement before we start.
A GOOD FIT WHEN
This is likely to help if...
- Power Query has grown organically and is becoming fragile.
- You combine files or heterogeneous sources.
- You want to reduce maintenance and improve refresh behaviour.
IT MAY NOT BE THE RIGHT FIT IF
- The transformation logic should clearly be rebuilt as a broader data-engineering solution.
- You only need a one-off data-cleaning script.
If the problem is real but the format is wrong, that is useful to know early. I would rather redirect the conversation than force the challenge into the wrong service.
POWER QUERY CLEANUP
Does every source change create another Power Query problem?
Bring me the problem, not a polished brief. A few sentences about what is happening and what you would like to change are enough to start.
Tell me what's happeningPREFER TO WRITE?
Send me a message.
You do not need a polished brief. Whether the topic is Power BI, Fabric, AI, team training, mentoring, coaching or simply a challenge that needs untangling, leave a few details and we can start from there.
SIGNALMESSAGECONVERSATION