Feedback requested: How would you build reverse lookups in Coda?

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! :blush:

3 Likes

Thanks for reviving this thread, @Andrei_Kharlanov , and for disagreeing with me too :slight_smile:

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” :stuck_out_tongue_closed_eyes:

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 :stuck_out_tongue_closed_eyes:).

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 :brain:
:point_right: making Coda as versatile and easy to use vs :point_right: 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:

1 Like

:wave: Hi! I’m Ramesh, a PM at Coda.

Thanks for sharing this feedback - the good news is we are opening a new beta for a new linked relationships feature (aka bi-directional lookups), that make things like setting up Projects + Tasks, Recipes + Ingredients easier. The following is changing:

  • We are renaming the Lookup column type and canvas control to Relation.
  • We are adding a new column type called Linked Relation that represents the other side of this relationship
  • When you add a new Relation column, a Linked Relation column is created automatically
  • Editing is enabled on both sides by default
  • Existing “Reverse Lookup” columns added via the “Referenced by” menu option will be auto updated to Linked Relation with editing enabled

We’d love to have you try this out and get your feedback. If you’re interested, please fill out this form and see this page for other betas that we are running.

Please note that signing up for beta access to this feature will enable it only for you and your docs in your workspace (both existing and new).

Linked Relationships - Projects and Tasks

4 Likes

Oh my gosh this is amazing news!!! This is huge for me!!! Signing up right now :smile:

It would be great if this feature could be turned on or off on a column by column basis rather than automatically creating the linked relation column. In Airtable, these ‘reverse lookup’/relation columns are a nightmare; and if you don’t need them for a particular application/table, they just clutter up the table and confuse users.

2 Likes

The Coda is team is on a bit of a roll with Betas these days and I’m loving it !

I am very excited about this and will follow up with thorough feedback as soon as I get my hands on it.
Something that immediately jumps to my eyes and that I think need saddressing is:

Editing is enabled on both sides by default

In 80% of my use cases, I only wish to be able to edit on one side, but I appreciate if a read-only column is created on the other side that can be referenced in formulas etc. I now achieve this using a Filter() formula, which seems to substantially slow down large docs.

Or…does this mean that we will have a way to disable editing on one of the sides if desired ?

A more general and powerful way to give this choice to the maker would be to allow us to disable editing on a column by column basis and using a formula - a suggestion which I would like to shamelessly plug here, since the PM gods at Coda are probably reading this thread :wink: :

2 Likes