This was supposedly very simple task but for some reason I am not getting my head around it, not sure if its an issue with Nintex or we need to approach this some other way.
My list has a user column and data is populated in the list. All i want to do is use the "Query List" Action and search for all records that have matching user populated in the column. But for some reason what ever query value I give it doesnt seem to select any records.
Where ADM owner is the user column in the SharePoint list and ownertxt is a single text variable. tried populating it with multiple different options.
I have tried most of the options below but wasn't able to query any record.
Can some one let me know how do you query a user column (as your filter) in Query list action.
Note - I am not interested in using the CAML editior as I will have manually change the list ID in different environments.
Solved! Go to Solution.
I think you will find it is trying to search the user id at the site level (i.e. Cassy Freeman on Site A may be user ID 6).
You can get this by choosing the return value of user ID against a people picker field - does that make sense?
Thanks very much for a quick reply. This is what I did before and now was thinking of changing the solution. User ID works but again userID is only constant at the site collection level (i.e. userid for the same user will have different id's in different site collection). To add to this its on lot of forum's as well that sometimes the userid in SP does get changed may be due to UPS being restored or anything else, so didn't want to depend on the userid.
Interestingly I think it might be a bug with Nintex because if you click on the CAML code for the same query I can see there that Nintex does add LookupID='true' which is the reason why its looking for userid rather than the display name, but if I choose to remove this "LookupId" from the CAML query (which means I have to use CAML query) then I would need to hardcode the listID and make sure it gets updated when its pushed between environments.
Note even sure why Nintex just assumes we want to search the user by their ID,
Thanks very much Cassy, didnt strike could have used "title" instead of guid's will have a look to see none of the business have the permissions to change this list title.
On a different note what is the regular usage when using query list action and when people column is involved? Do you also depend on userid for selection? have you used it in your projects? Just trying to weigh the risk before I change my code from selecting from userid to DisplayName.
this only cropped up for me recently - I rarely have to filter by a person field. but when I did I battled with it for ages until I realised the ID thing. So yes I have implemented it with IDs for now. be interested to see if anyone comes back with a better solution!
Make sense .. I was in the midst of a live deployment when this struck me and I thought its better to just move from id to a display name ( there would also be instances where the display name of anyone changes in the organisation but that would be a bit rare and could be communicated to the business)
At first when I developed this I did struggle a bit but the userid seemed okay for that time, its just that there is a bit of a critical business logic that is done based on this field that I had to think of moving it to display name because if SP behaves odd in any environment then dont want the entire thing to fail!
I probably think User comparison could be done via the claims token by stripping out the unwanted characters, but that's something Nintex should think about. (not sure how the ids would look if there any forms authentication though!)
Thanks again for your answer.
do I need to have a list which already has a value in order to populate the list with people that meet a certain criteria?
I am trying to create a list of all people in the AD with a particular title e.g. 'Credit Manager'
Would it be an acceptable workaround to use a on-create workflow for your lookup list, with the user to filter on, which stores either the selected user's display name, login name or email address in a (hidden, but after you updated your workflows) field and use this in your Query List filter?