Launched: Lookup Control

:white_check_mark: Checkboxes
:white_check_mark: Select Lists
:white_check_mark: Scales
:white_check_mark: Sliders
:white_check_mark: Dates & Times

. . . and hot off of last week’s :white_check_mark: Text Input control launch, we made a few quick tweaks to enable one more type of control for your docs: Lookups!

You can easily convert lookup columns to controls by clicking on the column header and then selecting “Filter” > "Interactive filter” > “+ Create control.”

Create Lookup Control.gif|775.1111111111111x436

Similar to other controls, you can also add them to any page using the slash command (in this case, simply type /lookup), and create filters using the Matches() formula. You can also edit your control settings by right clicking on them; this enables you to do things like change your source lookup table, allow multiple selections, determine the order in which selectable items are sorted, and more (be sure to expand the “Item settings” in the control settings to see all of your options!)

You can learn more about patterns using the Matches() formula in last week’s Text input control announcement.

Almost all docs should see this new feature today, although there are some docs still upgrading to include lookup controls. If you experience issues, our friendly Codans are available to help troubleshoot at



Another great upgrade! But…what if you already built this kind of select by creating a control and filtering unique from your table and then created the formulas for the filter to work properly?

Is there any reason/benefit to going back into all those and changing them to this new feature rather than leaving them as they are? They work, they will update depending on what fields are populated in the table. I’m wondering if there is any functionality difference, especially in calculating results, etc.

Has anyone done testing to see if there’s any difference?


Hi, Susan!

Great question. The biggest advantage to using the lookup control is we made the configuration UI available so that you can add filters and whatnot without needing to write formulas. Under the hood, the lookup control is basically the same as the select control, except we use [Table Name] as the selectable values formula.

If you only want the control to contain values from the lookup column, then keeping your existing select control should be fine, though technically the .Unique() call might incur some additional calculation cost. If there isn’t a huge delay when opening the control dropdown though, I wouldn’t worry about the extra calculation.

For context, I’ve been doing some refactoring for our performance work that just happened to make this control easier to implement, so we figured why not add a quick update along the way :slightly_smiling_face:


It will definitely be easier for new things. Just wondered if it was worth the time to go back and change existing.

You guys are great. Love the little changes.

Susan M. Davis


Great stuff! I haven’t had an opportunity to implement it yet, but am I to assume correctly that choices made here are unique to the doc, and not unique to the user?


Yes, that is correct. If you add a lookup control, it will be available to everyone using the doc, and the value selected will be shared among all users. In other words, it’s not user-specific.

1 Like

Got it!

I think this is a pretty common request, but it would be huge if when using a control that you could choose whether its selection is global, or unique to the user. Right now I’m using hacked together filter tables to do that sort of thing, which doesn’t always scale particularly nicely.


+1 @galligan
Docs are made to be shared so all these improvements are useless for almost every docs I produced…
It is time consuming to have a table to store the users choices and in this table we can’t use control like date range for example.
Hope Coda hears us.

1 Like

@Stephane @galligan Thank you for taking the time to write in feedback. We recognize that not everyone is satisfied with the workaround for controls. Although user-specific controls is not a project yet, it is something that we are discussing more and more.


Oh this is good - I had to use Shishir’s method of using another table, and using a filter = first().contains() (approximate formula, I don’t remember the exact formula) to do this functionality before.

1 Like

Super cool feature! I’m having a problem where the rows without a selected lookup option don’t appear in the table when I’m using a lookup control.

Hey, Hector! Do you mind reaching out to support via email ( or Intercom (click on the “?” in the bottom right corner)? They’ll be able to help you with your problem.


AWESOME! I have been waiting for this feature. Makes it so intuitive. Thank you team coda and @Kelsey_Chan !


Hi @Kelsey_Chan ,
I don’t understand why your priority is to develop these controls that us, paying users that create docs to share with our colleagues, can’t use.
What is the aim to have a doc with beautiful controls that only one person can use at a time ???
Or maybe am I alone creating and sharing docs for all my team ?

Hi @Stephane,

You’re not alone in creating docs for multiple people to use. It is however, wrong to think of features being rolled out as being in order of priority. Some features take longer than others to implement, some require foundational work to be done first, and others may conflict with current projects.

We do hear you that per-user controls are a priority, and they are for us as well. As a company though, we keep things moving across a large number of areas in order to keep growing and features being worked on are not lined up in a single file line and then worked on one at a time. We tackle a good bit across a wide range.

For now, if you do need per-user controls, this doc has some setups that might help out. This is your best solution until we’re able to include this in the product.

And keep an eye out for updates in performance over the next few months. I’m betting this is a priority for you as well and I think you’ll appreciate that its a focus area for us.


Hi @BenLee
Thank you for your answer.
I know you’re working hard and I thank you everyday for all you bring to us in Coda.

But your answer

is also in an opposite way of @Kelsey_Chan 's

Who’s right ?

It is so frustrating to see how easy it is to add a date range picker filter comparing to the two date columns filtered by user we need to do to have the same behavior but without a lot of options…

We are both right. It’s not a project yet, there are a few other things that need to get done first, but it is on the list and a priority.


Great feature. The functionality already existed, but reducing the complexity to get that functionality working is always a good thing. What used to be many clicks and some typing is now 4. Thanks!

Also want to take a chance to say I appreciate the work you are putting in. At the end of the day you are a business, but this software has been transformative for me and I am looking forward to whatever comes next. Keep taking the big swings.

1 Like

@Andrew_Adkins Thank you for your kind words! I joined Coda because I loved the idea of building software that empowers users to create solutions for their own needs, so your feedback makes me really happy! :blush: Looking forward to making the experience even better for you all :sunglasses:

Hi there, I’m struggling to get a Control to effectively filter multiple tables that use the same value. I’m trying to create a cookbook app that allows a user to pick a recipe from a list, and several tables then filter to the right info (ingredients needed, directions, prior reviews of the recipe, etc).

I re-created the basic structure of my Doc here, which demonstrates that only one of the tables correctly filters using a control. What am I missing?