Power Automate

The problem (dynamic filter fails, hard‑coded works)

(0) Share

Report

Posted on by LA-14041416-0

📄 Power Platform Support Ticket – Issue Description

Title

Power Automate – Get items Filter Query using dynamic value returns no results, while hard‑coded value works

Environment

Platform: Power Automate (Cloud flow)

Data source: SharePoint Online list

Trigger: Microsoft Forms (anonymous submissions)

List: T‑Track

Business Purpose

The flow is used to update inventory stock levels based on anonymous Microsoft Forms submissions from workshop operators.

Operators submit:

Part Number

Quantity Used

The flow should:

Find the corresponding SharePoint list item based on Part Number

Subtract Quantity Used from CurrentStock

Update the list item

Let SharePoint calculated columns (e.g. Reorder Status) recalculate automatically

Current Flow Logic (High Level)

Trigger: When a new Microsoft Form response is submitted

Get response details

Compose_NormalizedPartNumber
- Trims the Part Number text

Get items (SharePoint)
- Filter Query on PartNumber

Condition
- length(Get items value) > 0

Apply to each (1 item expected)

Compose_StockCalc
- CurrentStock - QuantityUsed

Update item
- Updates CurrentStock
- Passes required fields (PartNumber)

What Works ✅

✅ Hard‑coded Filter Query works perfectly

When the Get items Filter Query is hard‑coded like this:

PartNumber eq 'C6-570-40-RG'

Results:

Get items returns exactly one row

Subtraction logic works correctly

SharePoint CurrentStock updates correctly

Reorder Status recalculates correctly

✅ Update item action is correctly configured

Correct Item ID

Required fields supplied

Patch succeeds and modifies the item

✅ Quantity calculation works

Correct Forms internal field identified

Numeric casting confirmed

Compose_StockCalc outputs correct values when lookup succeeds

The Issue ❌

❌ Using a dynamic value in the Get items Filter Query does NOT work

When replacing the hard‑coded value with dynamic content from Compose:

Designer configuration:

PartNumber eq Body

(where Body is the output of Compose_NormalizedPartNumber)

What happens:

Flow runs successfully

No errors raised

Get items returns:

"value": []

Condition evaluates FALSE

Apply to each / Update item are skipped

Important detail:

The same value does exist in SharePoint

The same value matches successfully when hard‑coded

The column PartNumber is Single line of text

Internal column name is confirmed as PartNumber

The Compose output contains the expected trimmed value

Observed Peek Code Behavior

When using dynamic content, Peek code sometimes shows:

"$filter": "PartNumber eq '@{outputs('Compose_NormalizedPartNumber')}'"

Other times it appears to resolve to a literal value even before execution, which creates confusion.

This inconsistent behavior makes it unclear whether:

The dynamic content is being passed correctly

Or the SharePoint connector is failing to resolve it at runtime

What Support Is Requested ✅

I need help confirming one of the following:

✅ Whether this is a Power Automate / SharePoint connector limitation or bug when using dynamic Filter Queries

✅ The correct supported way to pass a dynamic value into the Get items Filter Query for SharePoint

✅ Whether additional configuration (encoding, format, or expression) is required even when using text columns

✅ Whether this is a known issue with the new Power Automate designer

Why This Matters

Hard‑coding Part Numbers is not viable (multiple parts)

The flow logic is otherwise correct and validated

This is blocking a production inventory automation

Attachments

Screenshots of issue

Categories:

Building flows

I have the same question (0)

All responses (3)

Answers (0)

Sort by

Vish WR 3,748 on at

Like
a
(2)

Report
Copy link

Link copied!

@LA-14041416-0

can you see if it’s fix

concat(
"PartNumber eq '",
trim(outputs('Compose_NormalizedPartNumber')),
"'"
)

Was this reply helpful? Yes No
Suggested answer

Riyaz_riz11 4,204 Super User 2026 Season 1 on at

Like
a
(1)

Report
Copy link

Link copied!

Hi,

The dynamic value has hidden spaces sometimes Compose looks correct, so instead of just using trim() in your Compose like trim(string(outputs('Compose_NormalizedPartNumber'))) to trim the data.

The filter query needs single quotes around the dynamic value in your Get Items filter query write it in advanced mode like this exactly: PartNumber eq '@{outputs('Compose_NormalizedPartNumber')}'

Switch to advanced filter mode and type it manually do not drag and drop the dynamic content into the filter box, instead of that use click "Edit in advanced mode" and type the expression directly as PartNumber eq '@{outputs('Compose_NormalizedPartNumber')}'

Debug Compose just before Get Items add a temporary Compose action that outputs exactly PartNumber eq '@{outputs('Compose_NormalizedPartNumber')}' and check whether the value is getting populated properly or not.

I hope this will helps you to resolve.

If I have answered your question, please mark it as the preferred solution ✅ . If you like my response, please give it a Thumbs Up 👍.
Regards,
Riyaz

Was this reply helpful? Yes No
LA-14041416-0 4 on at

Like
a
(0)

Report
Copy link

Link copied!
Thank you everyone for the support and guidance on this issue — I wanted to close the loop and share the actual root cause and solution in case it helps others.

In my case, the issue was not OData syntax or SharePoint, but Microsoft Forms branching behavior.

🔍 Root cause

My Form had multiple branched questions all named “Part Number” (4 sub‑branches).

Only one of those questions is answered per submission, while the others always return an empty string ("").

Power Automate still returns all branched questions in Get response details, which means:

Referencing a single Part Number field directly is unreliable

Most runs returned empty values depending on which branch was used

This explained why:

Hard‑coded Get items filter worked

Dynamic filter intermittently returned no results

Debug sometimes showed empty values even though the form looked correct

✅ Solution

I normalized all branched Part Number fields into one canonical value using coalesce() and empty‑string → null conversion:

coalesce(

if(equals(outputs('Get_response_details')?['body/rcf5a8fa112f64dcf8f8f555db2043542'], ''), null, outputs('Get_response_details')?['body/rcf5a8fa112f64dcf8f8f555db2043542']),

if(equals(outputs('Get_response_details')?['body/reb8f44b1029e487e8d0a63de641630ac'], ''), null, outputs('Get_response_details')?['body/reb8f44b1029e487e8d0a63de641630ac']),

if(equals(outputs('Get_response_details')?['body/r16f82901a0ec4ac5a0e2b60518fe981a'], ''), null, outputs('Get_response_details')?['body/r16f82901a0ec4ac5a0e2b60518fe981a']),

if(equals(outputs('Get_response_details')?['body/rca7166fbae8b4fc7b7607d391566a975'], ''), null, outputs('Get_response_details')?['body/rca7166fbae8b4fc7b7607d391566a975'])

)

Then I used this normalized output in Get items with an advanced filter

PartNumber eq '@{outputs('Compose_NormalizedPartNumber')}'

After this change:

Dynamic filtering works reliably

The correct SharePoint row is always matched

Inventory updates and calculated columns behave as expected

✅ Key takeaway for others

If you use Microsoft Forms branching:

Each branched question produces its own response field

Non‑selected branches always return empty strings

You must normalize these into one value before using them in lookups

Again, thanks to everyone who contributed — the guidance helped steer the debugging in the right direction.

Was this reply helpful? Yes No