Hi @duane, thanks for this question. I started looking into this and found that, like you said, I can limit the records returned in a table using URL parameters. I could also create filters on those same conditions, but I found that even though the URL parameter is “filtering” the data in the table, the active value set by the URL parameter isn’t surfaced in the filter itself.

I’ll check with the team here and let you know what I discover. In the mean time can you let me know more about your use case?

• Platform: (SFX if Skuid app installed in Salesforce or NLX for Skuid platform)


• Data source type:


• Field type you’re trying to use the conditions / filters on: (e.g. checkbox, text, picklist)

NLX using Postgresql

It would be great to send a customized url link with url parameters that would default the filter set fields.

For example:

A drop down for user defaulted with user id from url param

A date range defaulted from url parameters for begin date and end date

Hi Duane, thanks for sharing that information. I haven’t tried this out in postgres yet; we had some success on NLX with a different data source and a picklist field (single select, we didn’t try multiselect). Boolean fields were more complicated.

#1: Just parameters conditions and filters (less stable)

In theory, this is how it should work:

1. 
   

   Create a filter set with manual (not automatically-generated) conditions.

   
   


2. 
   

   When you set up the condition:

   
   

• 
  Content: URL parameter


• 
  Parameter: Name of your parameter


• 
  If this parameter is not provided then…: choose what to do, I like “deactivate this condition” so there will still be data in the table


• 
  state: filterable default on
  

3. Remember that the filters in the table and filter set can be set to to “remember last selected values,” so you may want to turn this off.

#2: parameters, actions, conditions and filters (more stable)

Note: While in some scenarios sending the URL parameters directly to filterable conditions works as expected, the Solutions team did recommend that it’s more stable to set up actions sequence that runs when the page is rendered to check the parameters, update the conditions, and filter the model accordingly. This way you can control the timing, so that the model will definitely query the way you’d like.

If I have some time over the next week I’ll check test it out in Postgres with something closer to what you’re doing and try to see if I can get a working example to share. In the meantime, I hope these thoughts can help give you some ideas.

Cheers