Save the date! Join us on October 16 for our Product Ops launch event. Register here.
Mar 28, 2019 11:38 AM
TL;DR version: Airtable’s recently added capability to limit linked-record selection to a specific view allows users to incorporate, to a degree, conditional logic.
The specifics: ‘Conditional logic’ can mean a lot of things: Any use of an IF()
or SWITCH()
statement is a form of conditional logic. Here, I’m using it in what’s become an increasingly common manner: to mean the limiting of available options based on an earlier choice.
For example, take a look at the following diagram.
The user selects one of five categories. Based on that selection, he or she is allowed to choose from a subset of five subcategories, taken from an overall population of 25 subcategories. This conditional restriction of choices not only helps reduce a potentially unwieldy array of options to a smaller, more manageable group, it also helps ensure the subcategory chosen is appropriate given the category already selected.
Admittedly, a 25-element list may not present an insurmountable challenge to the user — even though in the example illustrated, a full 80% of subcategories would be considered invalid for any of the potential categories. Imagine, though, a situation where each category has 25 possible subcategories, or where categories and subcategories consist of model and part numbers: The likelihood for error increases greatly.
Such is the situation this approach is meant to address. While it is far from a universal solution — as the following list of caveats makes clear — it should prove useful in a number of circumstances and use cases.
First, the caveats:
[Control]
table for conditional logic to work. The version discussed here and in the referenced base requires only category and subcategory tables to be linked to [Control]
; records may be added to the main table without any such preliminary housekeeping.A demonstration base can be found here. To examine the base, open it and duplicate it into your own workspace.
As you can see from the following screenshot, the base contains four tables: [Services]
is the main table; [Control]
is a one-record table used to manage display of the appropriate subset of subcategories; and [Categories]
and [Subcategories]
should be self-evident. (For the purposes of this illustration, I’ve borrowed categories and subcategories from MindBodyOnline, a SaaS business-management app for the wellness industry.)
To see conditional limiting in action, create a new record and select a {Category}
; you’ll notice your selection mirrored in {ViewControl}
. (In normal operations, both {ViewControl}
and {Alert:Mismatch}
would be hidden fields; I’ve left them visible to illustrate the underlying mechanism.) Next, select the ‘+
’ in {Subcategory}
and review the possible choices — but close the linked-record popup without selecting a subcategory. Delete your {Category}
choice and select a different category. Now, when you go to add a {Subcategory}
, your options will have changed.
If you select a {Subcategory}
and then change {Category}
, in most cases {Alert:Mismatch}
will be set to '1'
and (for Pro accounts) conditional coloring will flag the record as erroneous. (For all accounts, the {!}
field — not shown on the screenshot — will be set to '🔥'
to indicate an error.) (I say ‘in most cases’ because some {Subcategory}
s are valid for more than one {Category}
; 'Botox'
, for instance, is a valid subcategory of both 'Face treatments'
and 'Med spa'
.)
Details: The routines are largely self-explanatory. The only bit of trickery involved is using a single {Control}
record to track the current record’s {Category}
setting. The routine assumes only the record presently being edited will have a linked {Category}
with no linked {Subcategory}
, and sets the value of {ViewControl}
accordingly. From there, a chain of rollup fields is used to pass along the current {Category}
, eventually resulting in {Subcategories::DynamicFilter}
being set to '1'
. The value of {DynamicFilter}
is used to determine which [Subcategories]
records are visible in the <Subcategories::FilteredSelect>
view — which, in turn, determines which {Subcategories}
may be selected from [Services]
.
Nov 08, 2023 06:37 AM
Thank you so much...only pb...I just change the records with my data and nothing works... I don't understand why...as I am not touching to anything in the base structure, not event a field title..???
Jan 31, 2024 11:42 AM
Any updates on this? We have an internal list of four items that prevent us from using AirTable for our enterprises.
Apr 10, 2024 12:14 PM
We can now achieve that with filtering record selection by a condition.
Finally!