I talk about this a lot, and so I thought I would put something together to explain it a bit. My peers and I have come up with a pretty rock solid methodology to work with VRA/VRO presentation. It runs counter to what a lot of the industry is doing and counter to a lot of the examples provided by VMware (both within the plug-in examples and in the blogs). Usually, people tell me that they expect designed capability to present complex object types in "presentation" forms in a logical manner. This makes sense to me as well, and I would add that quickly displaying longer lists is also important. The challenge has been that we tend find that complex objects in forms are not handled well. Sorting, filtering, formatting hasn't been well represented by the presentation side of either VRA or VRO. Complex object lists are often long to load, have tree views that are difficult to navigate or search lists (Select value as) that only show part of the information. (complicated by multi-tenancy and name duplication)
Our answer to this: STOP USING COMPLEX OBJECTS IN FORMS!
Deliver to your users exactly what they need to see in the format that you (or they) want it to be in. If you have a list of active directory user objects that can be selected based on certain criteria, maybe you want the presentation to look like this...
Bob Bobson <bob.bobson@domain.com>
...or this...
Bobson, Bob (bobby123)
ETC.
Picking AD users from a default object field list will give you only the format that is designed for you. It may not be how you want it to be. Using the default object field list may have issues requiring you to wait for the next release. The same goes for EVERY object you decide to use. (VLANs, Resource Operations, Machines, Custom Resources, Catalog Items, etc etc)
What has always worked for us in ASD/XaaS is: Present strings in Presentation, Lookup Objects in Execution
With the new external capabilities in the IaaS design blueprints, we gain equal capability to use VRO Actions to create the list that WE WANT TO SEE -- in the order and methodology we want to see it in.
How Does This Work?
==================================
1. Have objects in mind that you want to get.
2. You need an action in VRO. It has to be able to get the objects that you need. The action has to convert the list of complex objects to a formatted array of strings for presentation (and later lookup of the object - so format with later identification in mind).
3. The list is presented to the end user in either a multi-select (array) or single select fashion.
4. The selection provides the input to the workflow (or sets the custom property value-s)
5. The input is used to look up the resulting object during execution and the object is used in the workflow process.
===================================
If this interests you further, let me know... and I can drop a couple of workable examples in this thread.
Happy Automating!
Sean