Subquery type determines how a subquery relates to the rest of a Configurable Joins query. There are two options: dependent and independent.
A dependent subquery uses the joins that Slate has already defined between tables, keeping the subquery connected to the base of the main query.
An independent subquery runs on its own separately configured base. Use an independent subquery when you need to work with data that isn't reachable through Slate's predefined joins — for example, to compare records across two tables that share a common field value, or to pull in data from a separate context entirely.
🤔 When should I use an independent subquery?
Independent subqueries aren’t usually needed. When in doubt, stick to dependent subqueries.
Dependent subqueries
Subquery exports and filters can dynamically return a variable number of related records within a single query output. Without a subquery, each related value would typically need to be configured as a separate export column—which isn't practical when the number of related records varies.
A dependent subquery draws on the joins that Slate has already defined, keeping it connected to the base of the main query. For example, in a query on the Person base, a dependent subquery export could concatenate all decision-scoped data for each person — pulling in only the decisions that belong to that person's application records, and returning them in a single column per row.
For more information, please see Subquery Exports and Subquery Filters.
⭐ Best PracticeLeave the subquery type set to dependent when building most subqueries.
Independent subqueries
Independent subqueries are used to reference data that may not be accessible through the main query's existing join structure. When the type is changed from dependent to independent, a category and query base will need to be selected for the subquery. The base determines what each row of the subquery represents, and independent subqueries can be built on any query base.
Identifying upcoming events with an independent subquery
One use for an independent subquery is to identify events that a person has not yet registered for. Because no form response exists yet, there's no relationship between the person and the event that a dependent subquery could follow.
In a query on the Person base, an independent subquery export with a base of Form could return the start dates of the next three upcoming events — regardless of whether a person has submitted a form response for those events. Use a concatenate output type to generate a list of these events, or a dictionary output type to use the data with liquid markup.
By default, all forms that meet the subquery's filter criteria are included in the concatenated list. Adding a row limit restricts the results. In this example, a row limit of 3 and an ascending sort on Form Start Date/Time ensure that only the next three upcoming events are returned.
✨ TipIf a person has already registered for an event, a dependent subquery can export that event's data — Slate can follow the join from Person to Form Responses to Form. Use an independent subquery to include events for which no form response exists yet.
Joining with an independent subquery
A subquery join is used to customize the data returned by a join, adding additional filters to define what record or object’s data is returned by the join. Independent subquery joins can be used to create highly specific joins from the base of your query to other data tables in Slate.
One common application is pairing records across two datasets that share a common field value — even when no predefined join exists between them. For example, an admissions team preparing for alumni interviews might want to identify prospective students who live in the same region as an available alumni volunteer. In a query on the Person base, an independent subquery join with a base of Alumni Volunteers and a Comparison aggregate can compare each person's active address region to the active address region of volunteers — creating a join between the Person record and an Alumni Volunteers record.
The same approach applies in other contexts: a student success team might pair incoming students with current students from the same home state for orientation programming, or an advancement team might match donors to region-specific funds or giving opportunities.
📝 Note
A subquery join returns only one matching record per row — the first match found. In this example, only one alumni volunteer will be paired with each person record. If you need to return data about all matching records, consider using an independent subquery export with a Concatenate output type instead, keeping in mind that all results will appear in a single column.
✨ Best PracticeRename all joins to be descriptive. In this example, comparing person records to volunteer records required two separate joins:
A join on the main query from Person to Address by Rank Overall, with a rank of 1
A join in the independent subquery from Alumni Volunteers to Address by Rank Overall, with a rank of 1
Renaming these joins to Person Active Address and Volunteer Active Address makes it easier to distinguish between them when selecting the fields to compare in the subquery filter.