Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 

July 7 - July 17 | Round 2 of the Power BI Dataviz World Championships. Don't miss your chance! Learn more

Reply
helspaul
Frequent Visitor

Order switching mid workflow

Hi, I have the most frustrating issue. Anyone seen this before? Know how to stop it? Is it a bug?

 

I have a basic table which records changes over time

helspaul_0-1772115246040.png

 

I want to add the date from row 2 to row 1 so I know the start and end date of the status 'NNC'

 

So I group my data by DefectID keeping All Rows, add an Index Column then expand. Each of my changes now has a sequential ID

 

helspaul_1-1772115370233.png

 

Then I create a unqiue key and create another key for the record I want to join. My rows are in Date order, and my Index, Start and End columns are all in the right order

 

helspaul_0-1772119768880.png

 

Then I merge using Start to End - everything is still in the right order

helspaul_1-1772119647545.png

 

Then I expand

helspaul_2-1772119666144.png

 

 

 

 

The expand is where this all goes wrong. The rows are in the same Date based order, but the Index, Start and End values have changed. The wrong row joins to the wrong row. 

 

When you flick between the steps you see the date order remain but the index, start and end change. And as a result the wrong end date is being added to the wrong row.

 

The data seems to revert back to the order it was read, but only part of it. I've tried breaking the process up into seperate tables with the same result. I've also tried adding sorting at various stages. I can make the Date order change and the Index, Start and End stay the same. But I can't make all the input values stay the same

 

Any ideas?

 

 

 

 

1 ACCEPTED SOLUTION
Juan-Power-bi
Super User
Super User

Hey, this is a really common gotcha in Power Query — row order is never truly guaranteed between steps, so when you expand after the merge, the engine can internally reorder things and your Index no longer lines up correctly.
The safest fix is to sort explicitly by DefectID + Date right before you add the Index column, and then make sure your key is built on both those columns together, not just the index. Here's what I'd recommend:

Before adding the Index, add a sort step: sort by DefectID ascending, then Date ascending. You can do this in the UI or in M like this:

m= Table.Sort(#"Previous Step", {{"DefectID", Order.Ascending}, {"Date", Order.Ascending}})

Then group by DefectID keeping All Rows, and inside each group add the index — this way the index is scoped per DefectID and the order within each group is controlled.
When you build your join keys, make sure they combine DefectID + Index so the match is always within the same defect.

The root cause is that Power Query's query engine doesn't treat intermediate sort steps as "sticky" — it's lazy-evaluated and can re-execute steps in a different physical order. Sorting immediately before the index generation is the only reliable way to guarantee they stay in sync.
Hope that helps!

View solution in original post

3 REPLIES 3
v-pnaroju-msft
Community Support
Community Support

Hi helspaul,

We are pleased to note that your issue has been resolved. Should you have any further queries, please feel free to contact the Microsoft Fabric community.

Thank you.

Juan-Power-bi
Super User
Super User

Hey, this is a really common gotcha in Power Query — row order is never truly guaranteed between steps, so when you expand after the merge, the engine can internally reorder things and your Index no longer lines up correctly.
The safest fix is to sort explicitly by DefectID + Date right before you add the Index column, and then make sure your key is built on both those columns together, not just the index. Here's what I'd recommend:

Before adding the Index, add a sort step: sort by DefectID ascending, then Date ascending. You can do this in the UI or in M like this:

m= Table.Sort(#"Previous Step", {{"DefectID", Order.Ascending}, {"Date", Order.Ascending}})

Then group by DefectID keeping All Rows, and inside each group add the index — this way the index is scoped per DefectID and the order within each group is controlled.
When you build your join keys, make sure they combine DefectID + Index so the match is always within the same defect.

The root cause is that Power Query's query engine doesn't treat intermediate sort steps as "sticky" — it's lazy-evaluated and can re-execute steps in a different physical order. Sorting immediately before the index generation is the only reliable way to guarantee they stay in sync.
Hope that helps!

Thanks for this. I tested it out and it did work. But just to be sure I also spoke to the team who make the API. They added the ability to sort on the date/time column. Now my data is being read in the order I need it from the start so Power BI isn't sorting it, and can't unsort it part way through. 

Helpful resources

Announcements
FabCon and SQLCon Barcelona 2026

FabCon & SQLCon – Barcelona 2026

Join us in Barcelona for FabCon and SQLCon, the Fabric, Power BI, SQL, and AI community event. Save €200 with code FABCMTY200.

60 days of Data Days Carousel

Data Days 2026

Join Data Days 2026: 60 days of free live/on-demand sessions, challenges, study groups, and certification opportunities.

Power BI DataViz World Championships carousel

Power BI DataViz World Championships - June 2026

A new Power BI DataViz World Championship is coming this June! Don't miss out on submitting your entry.

Top Solution Authors