ODATA Filter queries on LookUp columns from a SP List

[efialttes]

Hi again!

So, I have implemented a flow that executes a SP Get Items. I am trying to include an ODATA filter; the way I compose it is working fine, but it gives me an empty array as a result. ODATA filters are working fine for me so far if the ODATA expression targets a SP list String column...but do ODATA filters support queries agains a SP list LookUp columns?

The filter query expression I am using is:

AppPreloadSlotID eq 'Test | xxxxxx | xxxxx | xxxxxxxxxx | 20180119033416359'

UPDATE: I have found a thread in Flow Forums adressing this same issue https://powerusers.microsoft.com/t5/Building-Flows/OData-Filter-Query-on-SharePoint-Lookup-Site-Colu...

The thread was started in May 2017, just wondering if there is some new functionality covering this topic since then. I have tried also with the following ODATA filter expression, but I am getting a Bad Gateway error:

AppPreloadSlotID/Value eq 'Test | xxxxxx | xxxxx | xxxxxxxxxx | 20180119033416359'

Thank you in advance!

[v-yuazh-msft · Accepted solution]

Hi @ efialttes,

Using OData query to filter items based on Lookup column of SharePoint list is not supported in Microsoft Flow now, if you would like this feature to be added in Microsoft Flow, please submit an idea to Flow Ideas Forum:

https://powerusers.microsoft.com/t5/Flow-Ideas/idb-p/FlowIdeas

In condition, you could consider take a try to filter items based on Lookup column of SharePoint list using "Filter array" action.

I have made a test on my side and please take a try with the following workaround as an alternative way:

 

The “repairshop” column is a Lookup column of my SharePoint list, you could use the “Filter array” action to filter which “AppPreloadSlotID Value” is equal to “Test | xxxxxx | xxxxx | xxxxxxxxxx | 20180119033416359“.

The flow works successfully as below:

 

Regards,
Alice Zhang

[joshnystrom]

@JackWert clarified in this thread/post https://powerusers.microsoft.com/t5/Building-Flows/OData-Filter-Query-on-SharePoint-Lookup-Site-Colu... that this is a feature (and possibly always was, as I can't find any references to it as a new feature). The syntax is, as quoted from his post:

Super simple solution to this:

InternalFieldName/Title eq 'Lookup Value'

or

internalFieldName/Id eq 'Lookup Id'

Hope this helps someone!
Josh

[Network-iQ]

I have a similar issue, however, my lookup items are on a dropdown list.

I created a seperate list item that did not include a lookup but does have the items in a drop down. I cannot filter them, nor does the array filter return any result.

Is this something that is not possible?

Thanks

[joshnystrom]

Hey @Network-iQ,

I just did a bit of testing for this and from what I can tell, dropdowns (Choice columns) are treated a little differently. That is, they're actually simpler to filter because they're treated less like a set of attributes, despite their appearance in a JSON payload.

You haven't given a lot of detail around your specific situation, but from the generalities, I'd recommend just giving the ODATA filter a try using the simple syntax:

ChoiceField eq 'Desired value'

While the Choice fields in SharePoint are given Key-value pairs for ID and Value, those IDs and Values don't seem targetable from ODATA as they are with LookUp fields. Notably, Choice IDs are re-assigned according to the list order, making it difficult to gain anything by trying to stick to IDs anyway.

Hope this helps!

Josh

[Network-iQ]

Howdy -

Thanks for the reply.

Let me give you some specifics.

I want to be able to send a report that includes only the previous week's data on a specific customer. The Customer column is a lookup to a seperate list with customer contact info in it. I want to be able to output it to an email in table form. The HTML output array is perfect, and that does the job. Presently, however, if I use the ODATA filter, it gives me nothing. If I leave it blank, I get everything in the list.

I have two challenges. Number 1, the ODATA filter will not give me any output. I have it set up to look like this:

Customer eq 'ABC 123'

When I run it, the output is just [ ]

Secondly, I have been trying to figure out how to get nothing but the previous week's data. I think I can tinker that together, but so far it also pulls everything.

Any help you could offer is greatly appreciated.

Thanks!

[joshnystrom]

Hey @Network-iQ, that's a big help, especially as it clarifies which type of column you're looking to filter. In this case, an unfiltered Flow will bring back each of your data records with a Customer attribute that looks like this:

"Customer: {
"@odata.type": "#Microsoft.Azure.Connectors.SharePoint.SPListExpandedReference",
"Id": 6,
"Value": "ABC 123"
}

As a LookUp field, ODATA needs to be told which sub-attribute you want filtered. The important thing here is that if you're looking to filter by whatever populates "Value", then you actually need to provide the "True name" of the field targeted in the "Get information from:" section of the LookUp column's configuration.

So, if I have CustomerName selected as my target here:

then I need to go check what that Fields "True name" is on the Community Flow Outputs lookup list (viewable in the address bar when editing the target column)

and use that "True name" in my ODATA filter.

Give it a try with your CustomerName field called out specifically using the syntax from earlier in the thread. In my example I'd be using:

OutputLookup/Customer_x0020_Name eq 'ABC 123'

I've had mixed results filtering SharePoint list items based on date fields, so I'm not able to speak to it with confidence. If I dig into it anytime soon, I'll try to remember to funnel any insights your way.

Hope this helps!

Josh

[Network-iQ]

HI Josh -

Thanks for the reply.

The true name is actually 'Company'. I have to wonder if that causes an issue, however. List A is the customer contact info. List B uses a lookup for 'Company'. The name of both the field on list A and on list B is 'Company'. I am going to see if I can filter it using a different parameter. Otherwise, no change.

I shall post my results shortly.

[Network-iQ]

Well, if I use a non-lookup column, no problem. It works.

But that is not going to work. Haha.

Any ideas would be greatly appreciated.

Thanks

[joshnystrom]

Hey @Network-iQ, 

Yeah, non-lookups are way easier to use here (but much less useful, as you've noted!). While we go through this, if you could provide even more detail as to what specifically you're trying, I, or anyone else reading, may more easily notice anything not quite right. Simple screenshots of your filter and any error message you receive in the Flow action failure goes a long way (though typing it out helps make sure you're not sharing private information).

That being said, you've called out that the arrangement is perhaps a bit confusing, and the detail you've given already does help. I'm going to go out on a limb and guess that you're still just trying it as "Company eq" rather than the less intuitive (but correct):

Company/Company eq 'ABC 123'

Can you please confirm whether you're trying it exactly as above?

Thanks,

Josh

[Network-iQ]

Good lord...I was entering the information in the format you had suggested, but I had missed the fact  that your example used a slightly different term since you did not have all of the information. Company/Company worked perfectly. Thank you so much!

[joshnystrom]

Hey great, I'm glad it worked!
Cheers!
Josh

[Xv]

Is this possible yet? Looking to filter by a Lookup column.

Thanks

[OliverR-82]

---

@joshnystrom wrote:

@JackWert clarified in this thread/post https://powerusers.microsoft.com/t5/Building-Flows/OData-Filter-Query-on-SharePoint-Lookup-Site-Colu... that this is a feature (and possibly always was, as I can't find any references to it as a new feature). The syntax is, as quoted from his post:

Super simple solution to this:

InternalFieldName/Title eq 'Lookup Value'

or

internalFieldName/Id eq 'Lookup Id'

Hope this helps someone!
Josh

---

This post should be marked as Answer to the question instead of the one from @v-yuazh-msft . It is clearly a direct solution to the original question and not a workaround. The number of "thumbs up" on this post confirms this.

Also, I think it's a shame that the OP never even bothered to reply to the topic they started, not even a simple "thank you".

Thanks @joshnystrom for mentioning this, it works perfectly.

[Wilhelm]

Thank you, @joshnystrom - this worked perfectly for me!

[DennisTKuhn]

This should be the answer. Thanks a lot for sharing

[RichardDvorak]

This is perfect tip, I was trying to write proper filter code for days.

[vikas1606]

It worked for me!