Add a refresh time row index in Power BI
In Power BI Power Query, add an index column when you need to number the rows in the table at that stage of a query. Sort the example first, then use Add Column and Index Column with a start of 1. An index is useful for inspection and some transformations, but it is not automatically a permanent identifier for a person, order, or transaction. Refreshing changed data can assign a different number to the same record.
Create a reproducible example
Open Power BI Desktop and use Enter Data to create a small practice table. Add columns Code and Station. Enter R30 with Birch, R10 with Cedar, and R20 with Maple, one record per row. Name the table PracticeStations. Open Transform Data to work in Power Query Editor. These fictional codes let you see whether the index follows the input sequence or the sorted sequence without using business data or a live connection.
Write down the expected sorted order before adding the index: R10, R20, R30. The corresponding station names should remain Cedar, Maple, Birch. Sorting must move complete records, not independently rearrange the station names. In this example each code is unique and has the same text structure, so ascending text order is easy to predict. Real codes with inconsistent prefixes, spaces, or mixed data types need cleaning and a defined ordering rule before you rely on their displayed sequence.
Sort before numbering
Select the Code column and sort ascending. Confirm that Cedar is still beside R10. Then choose Add Column, Index Column, and the option that starts from 1. Rename the new column ReviewRow if that better explains its purpose. The result should pair R10 with 1, R20 with 2, and R30 with 3. Microsoft's Power Query guidance documents the index command and its starting-value choices. Ribbon wording may differ slightly between Power BI Desktop releases and other Power Query hosts.
Look at Applied Steps. The sorting step should precede the added-index step. Step order explains the meaning of the numbers. If you add the index first and sort afterward, the existing numbers travel with their records instead of being freshly assigned to the sorted positions. Neither arrangement is universally wrong, but they answer different questions. For this tutorial, the intended meaning is position after the Code sort, so preserve that order and give the steps descriptive names if needed.
Predict a changed source
Imagine adding R15 with Willow to the source before refreshing the query. After sorting, the sequence would be R10, R15, R20, R30. The new index would be 1, 2, 3, 4. R20 would move from review row 2 to review row 3. That is expected for a position label. It would be a serious problem if another table treated 2 as the permanent identity of R20. Keep this distinction visible in query documentation and column names.
You can reproduce the change by editing the Enter Data source step on a copy of the practice query, adding the fourth record, and reviewing the following steps. Check that Willow appears next to R15 and that every expected record remains present. Do not perform this experiment in an operational model without a safe copy. The exercise is a prediction and inspection task, not a claim that an index is stable across every connector, folding plan, or source-system change.
Define ties and boundaries
If two records share the same Code, sorting by Code alone does not explain which one should receive the earlier index. Add a meaningful second sort key when a consistent tie rule matters, such as an existing timestamp or a genuine unique source identifier. Do not invent a permanent identity from the order in which tied rows happen to arrive. If no suitable distinguishing field exists, document that limitation rather than disguising it with attractive sequential numbers.
Check whether you need numbering across the entire table or within separate groups. The simple command in this exercise numbers the current table as a whole. Restarting a sequence for each department is a different transformation and needs its own design and checks. Likewise, a row index does not fix duplicate records, missing records, or an incorrect join. Review those issues directly before using row positions as evidence that a dataset is complete or correctly linked.
Validate and describe the result
For the original three-row example, verify that the minimum index is 1, the maximum is 3, and there are three rows. Inspect the code and station pairs as well as the numbers. After adding R15, repeat the checks with four rows and a maximum of 4. These small checks catch an accidental filter or a misplaced transformation, but they do not establish the quality of a much larger production dataset. Keep source-level checks separate from the numbering exercise.
Close and apply the practice query when you are satisfied, then label the column in your model documentation as a refresh-time review position. As a reader exercise, predict what happens if R10 is removed before the next refresh. Which records get new numbers, and why would a source-system ID behave differently? Explain the answer to a colleague before using an index in a relationship. If the relationship requires permanent identity, choose a verified stable key from the data design instead.
