Filter by Related Objects¶

A Skuid model pulls in data from one primary data object located in one data source. Most filters work on the data fields that are directly pulled from the object. But it’s also possible to filter on data from parent or child objects that are included in the model.

For example, a Salesforce Case object is associated with the Salesforce Accounts object, because any Case would stem from an active account.

Similarly, the Account object is associated with the Contacts and Opportunities objects: the company surfaced as an opportunity; contacts were logged and deals negotiated; upon signing a deal, the lead converted to an account. So all three objects are linked by common data.

Parent and child objects¶

In many databases, objects/entities can have relationships, sometimes referred to as master-detail relationships (Salesforce) or, in Skuid, parent-child relationships.

Filtering on a related parent object can generally be done using automatic filters. Filtering on a related child object, however, calls for a slightly different strategy. The following case study walks through an example using standard Salesforce objects, but the principles can be extended to other Salesforce objects, or other data sources and their entities.

Case Study: filter records by related child objects¶

In this example, we’ll use a Salesforce Account object, and filter it by a contact’s state. (Contacts is a child object to Accounts.) We’ll use two models: one on the Account object and a second one (on the Contact object); this latter model is only used to snag the list of states where contacts live.

We’ll also use a condition on the Account model to limit displayed data to accounts that actually have contacts, plus a sub-condition on that condition, which further filters results to contacts who have a mailing state indicated.

Remember: These are just examples. This workflow can be used to create a filter on any standard (or custom) object by a related object.

Filtering by related child objects can be tricky: in this case study, the primary object uses a subquery condition on the primary object and a sub-condition on the related child object to filter the data.

Create the primary model¶

Create a new list page on the primary object (in this example, the Account object).
- Add fields to the primary model.
- Add a child relationship field for Contacts:
  - In Fields, click the Child Relationship tab.
  - Click Contacts.
Note

You don’t need to display this field. However, if you want to test that the filter is working correctly, temporarily display the field to assess the filter.
Under the model’s Fields list, click the Contacts field to open the list of fields associated with the Contacts child object.
- Select Name and MailingState.
Add the Contacts field to the table.
Click on the field, and edit:
- Template: Click the field picker, and add the Name and Mailing State fields.
Note

To increase readability, separate these with a comma.
- Delimeter: Type in <br>. If you have more than one contact for the account, this will place each on a separate line, making them more readable.
Click Save.

Create a condition on the primary model¶

In the model, click Conditions.
Click fa-plus-circle Add Condition to add a condition that will limit returned records to those that have contacts. Edit:
- Field: Select the ID field (i.e. AccountId), not the Name field, for the object.
- Value:
  - Content: Result of a Subquery.
  - Join Object: The related object (for this example, we’re using Contact)
  - Join Field: The relationship field selected in “Field” (above), in this case, AccountId.
- State:
  - Condition State: Filterable Default Off.
  - Condition name: Give the condition a helpful name.
Click on the condition just created, then click fa-plus-circle Add a Sub-Condition to further limit above condition.
Click the sub-condition, and make the following edits:
- Field: Select a geographical string field, such as mailing state, billing state, company state, etc. (For this example, use Mailing State)
- State:
  - Condition State: Filterable default off.
  - Condition name: Give the condition a helpful name.

Create a model on the related object¶

Click fa-plus-circle Add Models:
- Name: Something helpful like “ContactStates”
- Model Data Source Type: Salesforce
- Data Source: Your Salesforce data source
- Object Name: The related object, in our this case: Contact
- Model Behavior: Aggregate
- Max # of records (Limit): Make blank
Click on Groupings, and edit:
- Grouping Method: Simple
- Grouping field: Select the same geographical string field used in Step 4 of Create a condition on the primary model (i.e. mailing state).
Click Save.

Create the table¶

Drag and drop a table into the Skuid page.
Add the desired fields to the table.

Make the filters¶

Time to create the filter.

Drag and drop a Filter Set into the page and click Add Filter.

Note

You can also add a filter to the table itself by clicking on the table, then clicking Add Features and selecting Add Table Filter.

Set Model for the Filter Set to the primary model (i.e. Account).
Click the Filter button, and edit:
- Filter Type: Select Option
- Pick Options and Conditions: Manually.
- Model Condition to Affect: Choose the sub-condition created in Create a condition on the primary model, Steps 3-4.
- Create “None Selected” Option: Uncheck.
Click Add Source and edit:
- Source Type: Rows in a Model. The options for this filter will come from the related object model.
- Merge Source: Select the model with the related account (in our case, we’ll use ContactState).
- Option Label Template: This defaults to {{{Name}}}. Delete that, and select the state field from the picklist: {{mailingState}}.
- Which Conditions will this Source’s Options affect? Default condition and others.
- Value to Inject into the Default Condition: This defaults to {{Id}}. Delete that, and select the state field from the picklist: {{mailingState}}.
Click Add Effect and edit:
- Action: Activate
- Model Condition: Choose the condition created in Create a condition on the primary model, Steps 1-2.
Click Save, then click Preview.

The table displays accounts only the accounts that have contacts (the condition on the primary model); from that list, the filter selects those displayed accounts that have at least one contact with a mailing address in the selected state.

Not seeing all the options you expected for a displayed field?¶

Navigate to Model > Fields, and click the field.
Click the property tab.
- Max # of Records to display: This defaults to 10, but if you have many associated records, it may be useful to increase this number. In the example used to filter on a related child object, there might be quite a number of Contacts associated with a single Account, especially if that account is a large company. Unless this field is revised, Skuid will only display 10 of those contacts.

Creating filter labels when working with sub-conditions¶

The easiest way to label a filter is by checking Create “None Selected” Option in the Filter Properties, then filling in the “None Selected” Option Text with a short label.

However, when working with conditions and sub-conditions, this strategy doesn’t always work. Instead, try this:

Click the filter, and in the filter properties, click Add Source and edit:
- Source Type: Manual.
Click Add Option and edit:
- What Condition will this option affect?: Affect Other Condition(s)
- Label: Create a label to go on the filter.
Click Add Effect and edit:
- Action: De-Activate
- Model Condition: Choose the model condition to deactivate.
Perform the actions in Step 2 for all conditions on the model.

Once all conditions are deactivated, the Option created in Step 2 will activate.

Move the Source just created to the top of the actions list, just under the filter name.
Click Save and Preview.