<p>If you have Lava Entity commands enabled globally, you can use something like this to populate your single-select:</p>
<code>{% location dataview:'8' %}{% for l in locationItems %}{{ l.Name }}^{{ l.Guid }},{% endfor %}{% endlocation %}</code>
<p><i>(replace 8 with the Id of your dataview)</i></p>
<p>From there, you should be able to refer to the RawValue of this single select attribute to get the GUID of the selected location (which should in turn be the value you need to write to a location type attribute to have it populate as you'd expect</p>
<p>Let us know how that works!</p>

<p>here's what I tried ... I pasted the lava code into the Values&nbsp; for the Single Select field type for the attribute and when the form opened I got a list of GUIDs...<br></p><p><img style="width: 25%;" src="/Content/RockExternal/Users/sanford_bwd/Capture1.PNG" alt="Capture1.PNG"></p><p><img style="width: 25%;" src="/Content/RockExternal/Users/sanford_bwd/Capture2.PNG" alt="Capture2.PNG"><br></p><p><br></p><p><br></p>

<p>hey Michael I got it...I just removed '^{{ l.Guid }}' from the lava code and it showed my location name values in the single select dropdown just like I wanted...this is great because I will be using this little code snippet in several places...thanks so much...<br></p>

<p>Quite right, I had the values backwards. It should have been</p><pre>{% location dataview:'8' %}{% for l in locationItems %}{{ l.Guid }}^{{ l.Name }},{% endfor %}{% endlocation %}</pre><p>I do recommend doing it this way, so that you can use RawValue to populate a Location type attribute if you need it. But I'm glad you got it working for the time being :)</p>

<p>Hey Michael do you know if there's a way to dynamically supply the dataview ID based on the value of another attribute in the workflow ie. if I have an attribute A1 from another single select could I do like a CASE statement checking the id value of A1 and then setting the dataview ID value to something specific?<br></p>

<p>There's not a way to do that unfortunately; attribute options have to be able to be calculated when you save the workflow as well as when it runs; your attribute doesn't "exist" yet when you're saving the workflow definition. So you can't have attributes whose options are dependent upon other attributes...only attributes whose _value_ is set dynamically.</p>

<p>Hi Michael, I'm trying to take the single select dataview item another step forward...I'm making my own version of the basic Facility Request workflow and what I want to do is to change the attribute NewWorker from person type to single select with values coming from a dataview I've setup, similar to how the locations are working off a dataview...so my Person DV is just checking Person type to see if a person field attribute value is = yes and it displays Nick Name, Last Name, Gender and Email, no GUID...is that normal? ...so I would like to use the same lava code you gave me yesterday and i made a changed version that doesn't work..</p><p>{% location dataview:'8' %}{% for l in locationItems %}{{ l.Guid }}^{{ l.Name }},{% endfor %}{% endlocation %} changed to </p><p>{% person dataview:'24' %}{% for l in personItems %}{{ l.Nick Name }}^{{ l. Last Name }},{% endfor %}{% endperson %}</p><p>I thought this would work but the workflow won't save it...am I going down the wrong road again LOL??<br></p><p><br></p>

<p>1) Yes, it's normal for DataViews to not show a GUID field.<br>2) Person attributes are "stored" using PrimaryAliasGuid, so I would use this instead:</p>
<p><code>{% person dataview:'24' %}{% for p in personItems %}{{ p.PrimaryAlias.Guid }}^{{ p.NickName }} {{ p.LastName }},{% endfor %}{% endperson %}</code></p>
<p>Let us know if this doesn't work for you; I may be misunderstanding what you're doing/asking</p>

<p>YES!&nbsp; that worked perfectly...<br></p>