This is exactly aligned with my mental model as well!
1 Like
Hi @Ben_Huynh ,
I’ve given this more thought and I think I now understand the heart of what prompted this request. I’ve hinted at it in previous comments but those were a bit garbled since I was still getting my bearings.
The main behavior I want out of reverse lookups is for my user to be able to violate the table hierarchy in the name of user experience.
A great example of this can be found in this Sales Pipeline doc. It is a Codafied version of the Monday.com template.
Here’s the key difference between the two:
Monday
My user can take two approaches:
- Add a deal and then add contacts related to that deal.
- Add a contact and then add deals related to that contact.
There is no violation of the data structure, instead, Monday uses a clever “link to deal” selector which pulls up deals from another page. Then, when you select the deal for this contact it adds this contact to that deal’s Contacts column.
Coda
In Coda, this is not possible. As a builder, you can choose whether your user can add deals to contacts OR contacts to deals, but not both.
In this case, I opted to structure it so that Deals have Contacts.
This is unfortunate, because of course users will ask, "Why do I have to go back to the Sales Pipeline page to add a Deal? Why can’t I just add it here in the Contacts page?.
It’s not better to reverse the relationship and have each Contact have a Deal, since then people will ask exactly the opposite, "But why can’t I just add a contact to this deal? Do I really need to go to the Contacts page?
Workarounds
Of course, there are workarounds. One strategy might be to create a column called Add Deal in the [Contacts] table and then you can add a button called Add Deal. But then you’re basically rebuilding the functionality of reverse lookups and you’re doing it in a bad way, since you’ll also have to implement updating and deleting using your column button system as well.
Plus, if I’m your user I’ll take extra coaching. I might ask, "So I have to push the button to add it? Why can’t I just add it?"
@Paul_Danyliuk, does this make sense and help clear up your concerns that the data hierarchy?
I think this is a strong example of the need for this behavior. It also clarifies that this behavior is for the doc user, not the doc maker.
3 Likes
Hi,
Before any other consideration, I think coda is totally amazing… And so, as this feature is one basic feature, I simply don’t understand why coda doesn’t have it ?.. Every single other tool (notion, fibery, airtable, etc…) has it, so why ?.. For my usage, Coda is the one and only as it allows to do everything you can have in mind BUT this missing feature is a total game breaker…
So I wonder : you post your message 2 months ago, do you now more about when this feature will be release ? @Ben_Huynh
And my opinion about your question is : second option, we need to be able to refer to any field of the reverse lookup element and to filter, sum, formula, etc…
Thank you for your answer and for your incredible tool !
First of all, I’m super excited. Not having reverse lookups was the reason that I stopped using coda.
What I love about coda is it’s endless possibilities with formulas.
For this reason I suggest to go with most flexible approach for the user. We should be able to choose how many reverse lookups we want to have and also have the option to have none.
Just as a quick input: I like how relations (lookups) are setup in Fibery. May get some inspirations there 
And while we are at it. Consider renaming it (relationships?) and be very clear about implied hierarchy / direction. This can be one of coda’s most powerful features if implemented with enough flexibility.
2 Likes
I am very late to this, but wanted to add my two cents!
(1) My experience has been the following: (almost) every time I thought I wanted reverse look-up functionality, it has turned out that that the reason I thought I needed it was because I hadn’t really thought through my data structures, and once I re-thought things and got the relationships right the need went away. Not every single time, but most times for sure.
(2) Permissions: I really want users to have the clearest and easiest path to doing what they want/need, BUT I am also really concerned about giving users the power to screw things up. So when I look at the use cases described above, I am always thinking “who should have the ability to make changes to this other table, especially without having to look at that table first?”
What I really want is an easy-to-use permissions tool that can say: these users can make changes on these columns on these tables, can pick from select lists but not add new items to that list, and so on. My worry about reverse-look-ups is that I will accidentally give people more power than I meant to, and base data will end up editable in ways I didn’t want. That’s why I end up with lots of buttons - not because they are necessarily the best interface element for the purpose, but because they are controllable.
(3) I REALLY like the Monday.com solution @Connor_McCormick described. IF a user has permission to mess with the relevant table, then have the table details pop up and make the edits appropriately in the place they should be made.
(4) It would be good to have a better way to talk about relations. Lookup/select lists are clear, until you start adding formulas. Then it becomes much more complex to figure out what is really going on. I go back to my older docs and get lost as to what I meant and why. [COMMENTS IN FORMULAS PLEASE!!!]
1 Like
Sorry for the deviation of the recent discussion in this thread; I’d just like to connect solely to the project/task issue once more. Sorry also if what I describe is quite low level; I just hooked up to Coda some weeks ago and am still in the process of learning different concepts and solutions.
What I have some trouble with in my project/task setup is the idea (or necessity) of maintaining a separate table where projects live and having to interconnect to the task table by lookups.
This way the projects don’t live in my master task table and I don’t have the possibility to treat them similarly like tasks.
What I mean is that I’d like to have a project show up in my task table, in the corresponding area if I filter accordingly or at the right time when the project has a due date (and perhaps a start date as well).
My current approach is for a project in fact to be a task but defining it a project by giving it a special status “Project”.
I have set up a lookup column named “Parent” where I can define any existing task (which obviously has a “Project” status) as the current task’s parent.
And a Project gets a status “Sub-Project” instead if it has a project as parent.
This way projects are technically able to have any number of sub-levels and everything, projects, sub-projects and tasks, lives in my master task table. Conditional formatting helps in distinguishing the different entities.
By setting up a separate view where I filter all the tasks having “Project” or “Sub-Project” as a status and grouping accordingly, I get an overview of all my projects and their corresponding children, open and closed.
This is an example of the above, respectively the separate view for the projects I’ve described, where children are simply any tasks that have a parent defined.
If anyone would like to give any opinion of this approach, be it bad or good, I’d appreciate that very much.
1 Like
@Otto_Kiefer This approach exactly. What a people want/need sometimes is parent/child relationships, and those can be done with lookups WITHIN a table (or by using a support table that codes all the relationships, and gets read back into the master table).
I wish some of these relationships/dependencies were primitives (like in Fibery) and you didn’t have to reinvent the wheel every time…
1 Like
Yes, @Andrew_Milne , Fibery has a smart option to connect databases, while some of their other structural concepts are rather mind-bending, at least to me.
Personally, I just don’t recognize any advantage in separating projects and tasks into different tables as long as the lookup procedure in Coda appears too clumsy to me to feel intuitive.
This isn’t the real feature release, but it is a way to get linked columns:
I would prefer Multiple Reverse Lookup columns for additional flexibility, but with a twist.
Can’t it be both?
By default Coda can create Paired Lookups.
If a user needs additional Reverse Lookup columns, these columns can be created by:
right click on the Paired Lookup column header → select something like “Insert related Reverse Lookup column”.
Same as you can do with “Insert related column” for a Lookup column now.
And I strongly disagree with @Paul_Danyliuk that Coda doesn’t need this feature. I think it’s one of the top missing features that hold Coda back. Paired Lookups will make Coda so much easier to use, and docs will feel much more like real apps.
I greatly appreciate Paul’s examples and help in this community, but much of the functionality in some of his examples (like Best Practices Showcase (8 hours of videos & a doc)) is “hardcoded” and relies on buttons. And often you can’t drag and drop rows. Maybe sometime it’s good. Paul wrote it’s intentional:
If that’s what some docs benefit from, people can continue creating them the old way.
But many of us and our docs will benefit greatly from bidirectional Lookup columns.
Do it, @Ben_Huynh! 
3 Likes
Thanks for reviving this thread, @Andrei_Kharlanov , and for disagreeing with me too 
After the hackathon demo I actually sorta started liking the idea a tiny bit more.
Here’s what I think would make the most sense:
-
Add new column → Lookup → these top options should insert not an autoguessed “reverse lookup” formula but this new kind of an editable bidirectional lookup (a multi-select input column with a twist):
-
There will be these settings added to a Lookup column without a formula:
(it probably won’t be a formula but a column selection but you get an idea; could also just use blank selection instead of a separate toggle).
This way you’ll have the full flexibility of:
- Having regular editable lookup columns
- Having formula-based (non-editable) lookup columns
- Having regular editable lookup columns that are linked to a corresponding reverse-lookup column on that another table. Editing a value in one would automatically immediately edit a value on the linked one.
- And easy switching between the modes by adding/removing formula and/or selecting/deselecting the “Linked column” property in the settings.
5 Likes
It was actually not me who revived this thread.
I saw it by accident and thought “holly cow, Coda team was asking about opinions on bidirectional lookups and I missed it” 
It was @Connor_McCormick1 who commented here and named his community post as “Launched:…”. (And I think it’s a misleading name and shouldn’t be used by anyone besides Coda team, even his doc with buttons is a good workaround).
But I’m happy you’re more into bidirectional lookups now (after an elite non inclusive hackathon ).
1 Like
Haha I’m happy to change the title. Thought it was funny. Edited!
2 Likes
Hi! Is this feature still planned? Because like most people mentionner in the thread, this is a very important feature that limits people who are bringing in their workflow from Airtable. I absolutely agree that it should be bidirectional by default and could be turned off and become uni-directional as an option.
3 Likes
Hi! How is this issue solved? This is a critically important function for me. I’ve been setting up Coda for 2 weeks, and now I can’t use it because of the lack of this feature.
Paired Lookups - Necessary, Important, Urgent.
2 Likes
Hi,
It’s such an important feature, I can’t understand why this hasn’t been solved years ago… Any coda team member to answer us ?..
Friends! I suggest sharing links to this post in your groups and messengers to support this post with likes and comments, since the creation of this feature is very important for all of us. Even if you do without it today, the development of your applications will be problematic. This is the possibility of paired search and two-way editing. Together we will be able to draw the attention of developers to things that are really important to us. Thanks.
Hi Paul,
I was wondering if this feature was still on the roadmap as it is a top missing feature compared to all other tools…
Also, you said “I actually sorta started liking the idea a tiny bit more”… But why the hell don’t you like it ?.. It is so helpful !
Thanks and have a good day !
When I saw coda 3.0 is out this was the first thing I was hoping they implemented… unfortunately not.
My feeling is this is a very polarizing feature. The current coda users find a way around it, but there are many people for whom this is a deal breaker and they don’t start using coda until this feature is implemented.
Could this be developed externally by a pack in the future?
Best
4 Likes
Haha, very interesting to see two schools of thought 
making Coda as versatile and easy to use vs limiting functionality to make it human-error-proof
Personally I also believe two-way relationships would help us Makers focus less on workarounds and more on actual new developments 
1 Like