Grouping logic on model conditions are awesome. It would be nice if we could apply grouping logic on lookup filters as well.
The reason we have not further invested in filter specifics in lookup filters is that you can use a model as the source for your lookup options. (See Option Source in the Search Properties). This means you can use all the model features to make your lookup list as specific as you need.
Thanks Rob for your reply. Model approach works for me in almost all cases except one, ownerId.
If I want to assign a record (custom object record) to only group or only user or only selected users or selected groups, on what object and how should I create a model?
Owner ID looks up to the User Object. So make a model on User and filter as you wish. Use a subquery condition to filter down to groups.
Hi Rob, for custom object records, model on User does not seem to work. I already tried it. For example, if I want to get only Active users and all the groups on the owner field (rendered as picklist) how would I apply lookup filters or model. Neither model on User nor model on Group seem to work if I go with model approach.
Owner is a polymorphic relationship. So when you edit the field, you first choose which target object you are looking up. (In this case Users or Groups). When you put a lookup filter directly on one of these objects, and the field selected for the fitler is not on the second object, the filter is thrown out when there is not a field name that matches the filters field.
So if you filter users by “Active” - when you select groups, it should throw out the user filter and show you all available groups. This means that you don’t really need group logic on your filter. Nor do you need to use a model source for your lookup filter.
The reason the model source did not work, was that the lookup filter was looking for a particular Id. Since the Id field is available on both the User and Group objects, the condition was being applied to both - and no group records were being returned.
There is one wrinkle. The filter on “user = active” is not correctly creating the condition. It does not detect that the active field is a boolean and provide a checkbox for the value. You have to go to the XML and adjust the lookup field condition slightly. Make the eclosevalueinquotes value = “false”
See below: 
Hope that helps.
I’ve got this need to have grouping logic. My use case is that I’d like to look Tasks related to one of three object records that are related.
I’ve created an app to manage SF customizations. The three main objects are Project, Requirements w/ master-detail to Project and UATs w/ master-detail to Requirements.
I’d like to be able to filter which records are available for the whatid in the Task standard object. I can limit which objects are available to do a lookup on, but I can’t filter records to the current Project, its Requirements, and its Requirements UATs.
Pat, I’m not sure why this wouldn’t work. If you’re using Zach’s snippet to limit the objects, and only have one condition per object type in your lookup filters, I think it will work. What is happening when you search? No object returning? Or too many objects returning?
The snippet works fine in limiting which objects are presented in the first drop down. It’s the second input field for the whatid that I’d like to filter by. I’d like to ensure that at least one of three filter criteria are met. Right now, there is no option to set the grouping logic to “1 OR 2 OR 3”.
I was under the assumption that “Id” was a field on the Project object, “Project__c” was a field on the “Requirements” object and “Requirement__r.Project__c” was a field on the UAT object. You shouldn’t need condition logic if this is the case.
I’ve set it up with all three and only the Project Object is being filterered properly.
Strange though. Combining the last from the pic above works without issue, but adding the first filter messes up the other filters. Regardless of order. I’ve even tried changing the first filter to (param) id. No dice.
Pat,
Could you do this and let me know what you find.
- Put back all three conditions with model merges
- For each object type, inspect the network traffic coming back from the server to get the SOQL being generated for each search like in the picture below. To do this, click on the network tab of your chrome console. Then make sure the red “record” button is on. Next clear out all other network logs. Then do your search. An “apexremote” item should show up in your network log. Click on that and then go to the “Response” tab. Look through the response for the SOQL query that was generated.
- Post the SOQL queries
First: SELECT Name,Id FROM Project_mB__c WHERE ((Id = ‘a5q70000000s0qoAAA’)) ORDER BY Name LIMIT 51
Second: SELECT Name,Id FROM Requirement_mB__c WHERE ((Project__c = ‘a5q70000000s0qoAAA’))AND((Id = ‘a5q70000000s0qoAAA’)) ORDER BY Name LIMIT 51
Third: SELECT Name,Id FROM UAT__c WHERE ((Requirement__r.Project__c = ‘a5q70000000s0qoAAA’))AND((Id = ‘a5q70000000s0qoAAA’)) ORDER BY Name LIMIT 51
For some reason, the condition from the first filter is sneaking into the second and third filter.
Thanks Pat, I think this is a bug in Skuid then. I think it’s looking at if that particular object has that particular field, and if so, it’s using it in the filter. (Obviously all object have Id fields)
A workaround would be to create a formula field on your project object that just referenced the Id field, but was called something different. Specifically, named something that was not a field name on the Requirement or UAT objects.
That fixed it.
I’m glad it wasn’t me. I was starting to wonder why it was doing this.
