2 level lookups

Hi, Is this somewhat similar to what you are trying to achieve?

Possibly - if you edit something in your pop up, is it updating the Contact table?  I have a couple formula fields on the Contract User object that pulls data down to the Contract User table, but our guys need to be able to update the info in that pop up as well.

Interesting.   I think there are a few possibilities here. 

1. If you really have a lookup from Line Item to ContractUser (Contract User is the Parent object) then you can traverse the relationship from Line Item to Contact User to Contact  directly within the line item model and in that way show data about the contact either within the line item table or in a “More details” popup.  This more details popup shouldn’t need specific context conditions.  It should work automatically. 

2. The down side of option 1 is that you cannot edit the data on the contact.  If this is a requirement, you can do the following: 
 - Build a model on contact,  with a condition on the contact ID field that is filterable default off.   This model should not load data or create a default row.  
 - In your line item model add ContractUser.Contact.ID to the model  (traverse through the parent relationships)
 - On your line item table put a row action with the following mutli action sequence. 
        - Activate condition and send value:  Choose the condition from your contact model and pass it the “{{ContractUser.Contact.ID}}” value
        - Query contact model.  Choose the option to replace all data. 
        - Open popup.   In this popup I don’t beleive you will need to use context conditions, since the model will only have rows that are relevant to the line item selected. 
    
You might want to wrap those actions in a “block ui and show message” and “unblock ui” actions so the user is aware somthing is happening. 

In laymans terms - every time the row action button on the line item table is pushed the contact model is requeried, so it only retrieves the correct contact.  This is then displayed in the popup to view or edit. 

3.  On the other hand… If your lookup is from ContractUser to LineItem  - such that you can have more than one Contract User associated with a Line Item, you need to do somthing similar as number 2,  but with some wrinkles. 

- Your condition on the Contact model will be a subquery condition - joined to the ContactUser table such that contacts will be returned in the model only when they are in the set of records returned from the ContractUser object with the subcondition such that LineItem Id is the blank value passed by the filter. 
- Your action sequence will need to pass the “LineItem Id” from the line item row in context into that filter (So LineItem Id needs to be in the Line Item model). 

Obviously instead of a field editor in your popup,  you will put a table so you can show the muliple contacts that are associated with the line item. 


And that should bring a list of contacts that are related to your line item into your popup. 


Fascinating stuff… 

Indeed fascinating and AF is cool beans.  I intend to implement your suggestions so that I can better understand the options for future implementations.

2 is such a great trick.  I’m thinking through other places to leverage that idea.

This worked awesomely.

Thanks!

Glad to hear it worked.   AF is indeed cool beans.