Let’s say you have a field called Example on User. You put the following condition on an Element:
Current User’s Example is not empty.
Does that cost WU? Or is it evaluated client side since “Current user” is downloaded to the page.
tagging @boston85719
Run a test, takes 6 minutes
If the condition is evaluated client-side (which it will be on an element), and the relevant data is already loaded to the page (which is always the case with the ‘Current User’), then no additional WU costs are incurred.
If the condition is evaluated on the sever, and the data hasn’t already be used in the WF, then there will be WU costs for the retrieval of whatever data is required to evaluate the condition.
That said, it also depends on the type of data…
In your case, if the ‘Example’ field is another Datatype, and that field is NOT empty on the User, then referencing it in the condition will cause that item to be retrieved from the database and loaded to the page (assuming it hasn’t already been loaded to the page), obviously incurring additional WU cost for the data retrieval.
Makes sense, thank you!
Would that mean a count would be better since it would only ever do an aggregate search?
Count of what specifically?
Well, it’s not a ‘search’… it’s an ‘individual data request’ - which only costs 0.015 WU plus data - so in some cases, much less than an aggregate search (which costs 0.2 WU), although it could be a lot more depending on the amount of data, of course..
Counts can only be done on lists - so I’m not sure what you’re referring to there…
But if you’re asking whether the best way to check if a ‘list field’ has any items in it or not then definitely use count - this doesn’t incur any additional WU at all (assuming you’re just using the full count of items int he list) - whereas checking if the first item is empty will retrieve that item from the DB and insure WU.
I guess I was referring to “converted to list” with a count, sounds like that might be a better option depending on how heavy the data type is
