I am using SharePoint Designer 2010.
I created a workflow in which I needed to test the value of a lookup column. I (perhaps naively) simply tested if the lookup column equals the literal string I was testing for.
It didn't work. So, I slept on it and figured it probably had something to do with how SharePoint handles lookup values. After doing some testing and changing things back and forth it mysteriously started working, WOW!
So, I created another workflow, which needed the same thing to happen. Yet, this time it refused to work :/ So, I log the values it is seeing and observe that instead of returning STRING, the lookup column returns 1;#STRING (where 1 is the ID and STRING is the end user value of the lookup). Now, if I test for 1;#STRING, it works fine.
My question is, why does testing for the nominal value sometimes work (STRING vs 1;#STRING)? What is the secret sauce to convince SharePoint to equivocate the vanilla value of my lookup (STRING) to whatever it is returning in the background?
Obviously, I can work around this several ways:
1) I can use "equals 1;#STRING"
2) I can use "contains STRING"
3) I can use "ends with STRING"
None of these solutions are ideal.
1 seems like the best choice, but since I do not understand why STRING suddenly started working, I can conceive that 1;#STRING may suddenly stop working :(
2 and 3 suffer from returning too many results. (for instance if ASTRING is in the lookup column, it will yield true when I intend for it to yield false).
Ideally, understanding why it sometimes does and does not work would be the best solution. I suspect that when I was tinkering with it, I tripped some bug/feature that caused it to work as initially anticipated.
Finally, I know I am not the only one who has experienced this because when I was searching for answers I came across this question:
Notice, he too, finds that it wasn't working but then mysteriously was. However, his focus shifted from that issue as it was currently working for him - so no answer for me lies in that thread.