Right, but then the user cannot sort by the attribute to see how he might need to refine his search...if I have fifty customers who ordered a particular product, the user might need to sort by Customer to see how to further refine rather than just browse each result looking at the InformationPanel to notice the Customer.

Having it in the InformationPanel is often enough (and is what I will do for now), but long-term you might consider using the same idea as for the search columns in the results columns.

Thanks!

Great! Then you will want to create a Browse Information Panel.  You can do literally anything you want within this panel.  When a row is selected, then you can load up orders, etc.  In fact, the sample CRM application shows how to do this very thing.

Yes, basically. OrdersBO does not have a Customer property--only CustomerID. But I want to display Customer. Thanks!

I am a little confused as to what you are trying to do.  I think you are wanting to show records (or values) within the results list that do not belong to the BO.  If this is the case you can do this a number of different ways.  Before I go into an explanation on this you might verify if this is what you are attempting.

It would seem to be natural that you would often want to display in the results a superset of the fields that the user may search on. But of course, showing 'CustomerID' in the results is less meaningful than showing 'CustomerBO.Name'.

This is particularly true when the user is browing results based on search criteria other than the one in question. For example, searching for customers who ordered a particular item might bring up fifty different records. Clearly the name of the customer is better in this scenario than a lone ID to let the user know whether he should refine his search.

An alternative to direct support a la SearchFields would be to allow the BusinessObjectType to be of Type V while the BusinessObjectToPopulate could be of Type D. And then provide a mapping from properties of V to properties of D, or more simply, require that the set of properties of V be a subset of the set of properties of D. In other words, populate the BusinessObjectToPopulate with the fields required by its type, assuming the same properties will always exist on the BusinessObjectType (Type V).

The developer then could simply define a view of the desired type where all the lookup values are expanded. I typically have at least one such view on any interesting type anyway to make reporting easier. So using the earlier example, I would have CustomerID, CustomerName, CustomerSortOrder, CustomerCreationDate, and so on and so forth, all as part of my expanded Orders view that was my everything-under-the-sun view of all potentially interesting data points about Orders.

Whew! Hope that made sense...