Multi-Select filter option for non-picklist fields

In the new Superbank release, there’s now the option to add a multi-select filter to a table. This is great but only seems to allow picklist fields to be used. We really need to be able to use fields like “OwnerId” (for multiple user filtering) and “RecordTypeId” (for multiple record type filtering). Could we not provide a model for the selectable options like we can currently with a regular “select option” filter?

It would also be great if the new automatic condition table filtering could use non-picklist fields.

Oliver, we are working to expand the scenarios where Multi-Select filters are available — didn’t make it into the initial Superbank release, but it may appear soon, stay tuned!

I second this.

Got this work without issue by manually setting the table filter type to “multiselect” and conditions to multiple specified values.

Resulting queries work as expected.

You may have discovered a feature we didn’t specifically build. Cool!

As of the GA Superbank release, which has been pushed to all Production and Sandbox orgs as of last Friday night, Multi-Select filters are available on Picklist, Multipicklist, and Reference (lookup/master-detail) fields. So you shouldn’t have to use Pat Vachon’s hack to get this to work, we spent a lot of time working on adding in Reference field support over the past month.

Maybe I’m missing something but I can’t figure out how to get it to work. I don’t get “Pick Options and Conditions” when selecting “Multi Select Option” as the filter type.

I want the options to only be from another model I set up where the records are related to the current “Job”.

Pat, some mis-communication here — you are correct, there is not a “supported” way to do a Multi-select Filter where you “Pick Options and Conditions”, so your method works for this approach. What I was referring to is the ability to do Multi-selects on Reference fields where Pick Options and Conditions is “Automatically” — this is the new capability. So no, there’s no supported way to do it manually on Reference fields where you pick a Model source to use, but you can do it Automatically.

I’m still missing something then.

Pat - what version of Skuid are you running in this org? 


Weird,  cuz I can get the type ahead to populate values for reference fields in aggregate models… Both directly on the object and on the parent object. 

We recognize that the type ahead is not as intuitive as the classic multiselect control.  But we are worried about large volumes of relation values.  It seems the type ahead allows for more easy finding.  We are still looking at some Ux optimization here. 

I’m ok with type ahead, but I don’t get the option to limit which values are available like I can when I specify that the values come from a model.

The multiselect doesn’t seem to hit the nail on the head. Here are the results of the two.

  1. Built in functionality

  1. Hacked method

As I said earlier,  the hacked method is going to be problematic when you have 100 records in your reference.  We might set some boundary like we do on option select filters,  but that’s what it is…   

How else would you like the nail hit? 

The auto create one doesn’t render ever as a multi select on a reference field.


Any news or workarounds available regarding this issue?
Would it be possible to populate a table filter from JS snippet? If so, how?

I need to show a multi-select table filter based on a Reference field but with the look & feel of a “normal” picklist table filter.


Pedro, so you want a Multi-select Filter based on a Reference field that looks like a single-select table filter? How would the user be able to select multiple Reference field values using the single-select picklist? Skuid already allows you to do Multi-Select on Reference fields, and the UI is the way it is precisely because the single-select UI doesn’t make sense when picking multiple values. 

Hi Zach,

Not realy, what I realy need is a multi-select table filter based on a Reference field that looks like the multi-select picklist as shown in the picture (based on the values of the reference field values in the table:

Okay, I see. That makes sense.