Expression.Error: We cannot apply field access to the type Function.

In Power Query, Expression.Error: We cannot apply field access to the type Function occurs when you attempt to extract a column or field using record/field projection [Field] directly from a function name, because you omitted the function’s parentheses and arguments.

Quick Answer

Look at the formula bar for the step triggering the error. You wrote Function[ColumnName] instead of Function(Arguments)[ColumnName], or omitted the each keyword inside a row iterator. Add the required argument parentheses or insert the missing each before your column reference.

---

Why Field Access Fails on Functions

In Power Query M:

• Field access notation uses square brackets: Record[Field] or Table[Column].
• Functions are values that must be invoked with parentheses: Function(arg1, arg2).

If you write a function identifier without parentheses, Power Query treats it as a pointer to the function itself, not the evaluated result of that function.

Applying [Column] directly to a function pointer causes the engine to evaluate the expression as:

“Attempting to access field [Column] on a value of type Function.”

Because functions do not have fields or columns, execution immediately stops.

---

Most Common Causes and Fixes

1. Missing Parentheses on a Step Reference or Table Function

If you are calling a function that generates a table and immediately indexing into a column, omitting () leaves the object as a function type:

• Faulty Code: Custom1 = Excel.CurrentWorkbook[Content]
• Why it fails: Excel.CurrentWorkbook is a function. It has not been executed.
• Corrected Code:
  Adding () invokes the function, returning a table. The [Content] field selector then extracts the column successfully. Custom1 = Excel.CurrentWorkbook()[Content]

2. Omitting the each Keyword in Custom Columns or Filters

In functions like Table.AddColumn, Table.SelectRows, or Table.TransformRows, the condition argument requires an anonymous row function. If you write the column reference without each, Power Query evaluates the column projection against whatever ambient variable is in scope, or confuses the expression context:

• Faulty Code: #"Filtered Rows" = Table.SelectRows(Source, [Country] = "Canada") Depending on how the surrounding formula is structured, this either throws a scope error or treats the calling function as the evaluation target.
• Corrected Code: #"Filtered Rows" = Table.SelectRows(Source, each [Country] = "Canada") The keyword each is syntactic sugar for (_) => _[Country] = "Canada". It tells the engine to access [Country] on each row record _, not on the surrounding function.

3. Misplaced Closing Parentheses

A misplaced closing parenthesis often shifts the square bracket field reference onto the function instead of its output:

• Faulty Code: #"Extracted Value" = Table.SelectRows(Source)[Column] Here, Table.SelectRows requires two parameters: the table and the condition. If closed prematurely, Power Query evaluates Table.SelectRows as an invalid partial call or misapplies the indexer. Ensure the function call is fully and correctly closed before indexing into its return value:
• Corrected Code: #"Extracted Value" = Table.SelectRows(Source, each [Status] = "Active")[Column]

4. Shadowing a Table Name with a Standard Function Name

If you rename a query step to match a built-in M function name (for example, naming a step DateTime or Text), referencing DateTime[CreatedDate] will refer to the built-in library function DateTime, not your table step.

• Fix: Rename your step to something distinctive like #"Extracted Dates" or #"DateTime_Table" so it does not conflict with native M library types.

---

Diagnostic Checklist

When this error appears:

1. Select the step in the Applied Steps pane and view the formula bar.
2. Scan the line for every occurrence of [ (square brackets).
3. Check the identifier immediately preceding [:
   • Is it a standard M function (like Excel.CurrentWorkbook, Sql.Database, Table.Distinct)? If so, insert the missing () or pass the required arguments before [.
   • Is it inside a row-level condition (like Table.SelectRows or Table.AddColumn)? Ensure each precedes the column expression.
4. Hit Enter to re-evaluate the step.

If your formula syntax is correct but you run into unexpected data type mismatches after extracting the field, consult How to fix “Expression.Error: We cannot convert a value of type List to type Table.” to ensure downstream steps process the extracted data format correctly.