Power BI Course
Applied Steps in Depth
Applied Steps is the backbone of everything Power Query does. Every transformation you make is recorded as a step, and those steps run in order every single time the data refreshes. Most users treat the Applied Steps list as read-only — they add steps and hope for the best. This lesson teaches you how to fully control the list: rename steps, reorder them, insert new ones mid-sequence, delete them safely, and diagnose the errors that appear when a step breaks because something earlier changed.
The Applied Steps List — Full Anatomy
| OrderID | OrderDate | Revenue |
|---|---|---|
| 1001 | 2024-01-05 | 1,200 |
| 1002 | 2024-01-18 | 850 |
| 1003 | 2024-02-03 | 430 |
| UI element | What it does |
|---|---|
| Step name (click) | Selects the step. The preview grid rewinds to show the table as it looks after that step runs — all subsequent steps are ignored in the preview. The formula bar shows this step's M code. |
| ⚙ gear icon | Opens the settings dialog for that step — the same dialog that appeared when you originally created it. For a filter step, reopens the filter dropdown. For a type change, shows the column type list. Not every step has a gear (some are only editable via the formula bar). |
| Step name (double-click) | Makes the step name editable inline — rename it to something descriptive. Renamed steps are far easier to maintain when someone else (or future you) opens the file six months later. |
| Right-click a step | Reveals the full context menu: Delete, Delete Until End, Rename, Edit Settings, Move Up, Move Down. These are covered in detail below. |
How Steps Reference Each Other
Every Applied Step in M code references the step before it by name. This is why the order of steps matters, and why renaming a step without updating the reference can break the query. Understanding this chain is key to safely editing steps.
let
// Step 1 — reads the source file
Source = Excel.Workbook(File.Contents("C:\Data\Orders.xlsx"), null, true),
// Step 2 — navigates to the Orders sheet
Navigation = Source{[Item="Orders",Kind="Sheet"]}[Data],
// Step 3 — promotes row 1 to headers
#"Promoted Headers" = Table.PromoteHeaders(Navigation, [PromoteAllScalars=true]),
// Step 4 — sets column types
// References "Promoted Headers" by name
#"Changed Type" = Table.TransformColumnTypes(
#"Promoted Headers",
{{"OrderID", Int64.Type}, {"OrderDate", type date}, {"Revenue", type number}}
),
// Step 5 — removes blank rows
// References "Changed Type" by name
#"Removed Blank Rows" = Table.SelectRows(
#"Changed Type",
each not List.IsEmpty(List.RemoveMatchingItems(Record.FieldValues(_), {"", null}))
),
// Step 6 — filters out Cancelled orders
// References "Removed Blank Rows" by name
#"Filtered Rows" = Table.SelectRows(
#"Removed Blank Rows",
each [Status] <> "Cancelled"
)
in
// The last step name here is what loads into the model
#"Filtered Rows"
Renaming Steps
Power Query auto-generates step names like "Changed Type1", "Filtered Rows2", "Removed Columns3" — generic names that tell you nothing about what the step actually does. Renaming steps is one of the highest-value maintenance habits you can build.
Deleting Steps
Deleting a step removes it from the Applied Steps list. The step below it now receives input from the step above the deleted one — which means the data it receives will be different than before, potentially causing errors in that step and everything below it.
Reordering Steps
Steps run top to bottom. Moving a step changes what data it receives as input and what it passes to the steps below — which frequently causes errors. Reordering should be done carefully with a clear understanding of what each step depends on.
| Scenario | Safe to reorder? | Why |
|---|---|---|
| Move "Sort Rows" before "Filter Rows" | Usually safe | Sorting does not add or remove columns. Filter then sort and sort then filter produce the same final table for most cases — though sorting before filtering is slightly less efficient. |
| Move "Changed Type" before "Promoted Headers" | Will break | Changed Type references columns by name (e.g. "OrderDate"). Before Promoted Headers runs, those columns are named Column1, Column2 — the names do not exist yet, so the type step errors immediately. |
| Move "Remove Blank Rows" before "Changed Type" | Safe | Remove Blank Rows operates on row values, not column names. It does not care about types. Removing blank rows either before or after setting types produces the same result. |
| Move "Renamed Columns" before "Removed Columns" | Depends | If "Removed Columns" references columns by their old names, moving rename before remove means the remove step can no longer find those names. If it references by new names, it is fine. |
Inserting a Step Mid-Sequence
One of the most useful — and least obvious — skills in Power Query is inserting a new transformation step between two existing steps. By default, new steps always append to the end of the list. To insert mid-sequence, you first click the step you want to insert after, then perform the transformation. Power Query inserts the new step at that position.
Scenario: You forgot to remove blank rows before setting types.
Current step order:
1. Source
2. Navigation
3. Promoted Headers
4. Changed Type ← you want to insert BEFORE this
5. Filtered Rows
6. Renamed Columns
How to insert a step between step 3 and step 4:
Step 1 — Click "Promoted Headers" in the Applied Steps list
(this selects step 3 as the active step)
Step 2 — A yellow warning bar may appear:
"Editing this step may affect subsequent steps"
Click Insert Step to proceed
Step 3 — Perform the transformation:
Home → Remove Rows → Remove Blank Rows
Step 4 — Power Query inserts the new step at position 4:
1. Source
2. Navigation
3. Promoted Headers
4. Removed Blank Rows ← inserted here
5. Changed Type ← automatically updated to reference
6. Filtered Rows the new step above it
7. Renamed Columns
Power Query automatically updates the reference in
"Changed Type" to point to "Removed Blank Rows" instead
of "Promoted Headers".
Step Errors — Causes and Fixes
A broken step shows a yellow warning triangle or a red error message in the Applied Steps list. Every step below it also fails because it receives invalid input. The key to diagnosing step errors is working from the top of the list downward — the first step that shows an error is the one to fix.
| Error message | Cause | Fix |
|---|---|---|
| Column 'X' wasn't found | A column the step references by name was renamed or deleted in the source or an earlier step | Click the step → open the formula bar → update the column name to match the current name. Or click the ⚙ gear to reopen the step's dialog and reselect the column. |
| We couldn't convert the value to type Date | Changed Type step is trying to set a column to Date but the column contains text values that are not valid dates (e.g. "N/A", "", "TBD") | Add a Replace Values step before Changed Type to replace invalid values with null. Then the type change can proceed. |
| Formula.Firewall: Query references other queries | A query with Private privacy level is referenced by a query with a different privacy level — Power Query blocks the combination | File → Options → Current File → Privacy → set to Ignore Privacy Levels. Or align the privacy levels of all related queries. |
| DataSource.Error: File not found | The source file was moved, renamed, or is on a drive that is not accessible | Click Source step → click ⚙ gear → update the file path in the dialog. Or Home → Data Source Settings → Change Source. |
| Expression.Error: The name 'X' doesn't exist | A step references another step by name that no longer exists — usually caused by renaming a step in the Advanced Editor without updating the reference in the step below | Open the Advanced Editor → find the broken step → update the reference name in the step to match the actual name of the step it should receive input from. |
Editing Step Settings vs Editing M Code Directly
For most steps, there are two ways to edit them. Choosing the right approach saves time and avoids introducing syntax errors.
Type change steps — reopens the type list
Merge/Append — reopens the join dialog
Replace Values — reopens the find/replace dialog
Group By — reopens the full Group By dialog
The gear is the fastest and safest approach for any step that has a UI-based dialog. No M syntax to worry about.
Making small precise changes to a single value
Updating a column name reference after a rename
Adding a second condition to a filter step
Any change the UI dialog cannot express
Click the step → edit the M expression directly in the formula bar. Press Enter or click the green checkmark to commit.
Teacher's Note: The most dangerous habit in Power Query is deleting steps without checking what comes after them. Before you delete any step, click through every step below it in the list and confirm none of them reference the column that step created or renamed. The safe approach is: click the step just below the one you want to delete, look at the formula bar to see what it references, and only then proceed. Two minutes of checking saves an hour of fixing cascading errors.
Practice
Practice 1 of 3
You want to insert a "Remove Blank Rows" step between "Promoted Headers" (step 3) and "Changed Type" (step 4) without moving to the end of the list. The correct approach is to first click ___ in the Applied Steps list to select it as the active step, then perform the Remove Blank Rows action.
Practice 2 of 3
After updating your source Excel file, a step shows the error: "The column 'Revenue' of the table wasn't found." This most likely means the column was ___ in the source file or an earlier Power Query step.
Practice 3 of 3
You want to discard steps 5 through 9 in one action and return to the state at step 4. You right-click step 5 and choose Delete ___ End.
Lesson Quiz
Quiz 1 of 3
You open the Advanced Editor and rename the step "#"Removed Blank Rows"" to "#"Remove Blanks"" by editing the text directly. The very next step in the list immediately shows an error. Why?
Quiz 2 of 3
Your Applied Steps list has 10 steps. You click step 6 and notice the data preview shows 450 rows. You click step 7 and the preview shows 448 rows. Step 10 shows a "column not found" error. Where should you start debugging?
Quiz 3 of 3
You want to change the filter value in a "Filtered Rows" step from "Cancelled" to "Returned" — the business logic changed. What is the fastest and safest way to make this change?
Next up — Lesson 19 covers Transforming Rows and Columns — every technique for removing junk rows, promoting headers, filtering, deduplicating, renaming, reordering, unpivoting wide tables, and reshaping data before it reaches your model.