Launched: New and improved ways to connect data with Linked Relations

Lookup is now relation!

relation gif

We’re making major improvements to one of Coda’s most powerful capabilities: how you connect your data. Most importantly, you’ll notice the following changes:

  • The lookup column type and canvas control will now be called relation to better reflect relationships created between data.
  • A new column type named linked relation will represent the data on the other side of this linked relationship, replacing what is currently known as a reverse lookup. This type of column could previously only be setup via formula. Now, you’ll be given the option to generate a linked relation column on the secondary table whenever you create a relation. Within the column settings, you can toggle two-way editing of the linked relationship on or off.

linked relations.gif

How can I use relations and linked relations?

Quickly link your OKR statuses to your initiatives table and connect your team roster to the tasks everyone is assigned. Edit your selected launch dates and task statuses from either one of the tables they’re linked on. That’s just the beginning — we can’t wait to see how you use these new relational data capabilities to let your teams to get even more done with Coda.

Relations and linked relations are now available in all your new and existing Coda docs. Note that creating a new linked relation will mean that two-way editing is toggled on by default, but your existing reverse lookup formulas that will be converted to linked relations will not be two-way editable by default. You can toggle this on or off in the column options anytime.

Try creating a linked relation in your doc today and let us know what you think below! :point_down:

46 Likes

THANK YOU!!! This has been my #1 Coda desire since my first day with Coda. Thank you!!!

12 Likes

Best Seven-Word-Update EVER!!! So excited for this! Thanks (and HUGE kudos) to the entire team for making this possible! You guys and gals are simply the best!!!

12 Likes

“Two way editing”

Yes! Finally! Yes!

Ohhhh I am going to have so much fun with this!! :grin:

4 Likes

Yaaayyyy :partying_face: !!!

Thank you so much Dear Codans :raised_hands: !!!

As I’ve been part of the beta, I’ve seen this feature evolving quite a lot from start to finish and I can’t tell you how happy I am with the final result :raised_hands:

Out of curiosity though :innocent:, as this type of field is quite unique (I mean, a 2 way sync + formula under the hood, that’s not something we see everyday :smile: )… How did you do it ??? :grin:

Could you give us some details about the process, the idea that powered this absolute beauty ? :raised_hands:

But also, did you had fun while building it :smile: ?

I’m sorry, I’m just very curious (:innocent: )

… Anyway, Thank you :raised_hands: ! Thank you so so so very much to the whole team :raised_hands: !

8 Likes

Hi Pch,

That’s a great question. I was the PM leading the linked relations project so I can shed some light on this.

Historically, we opted to base Coda’s data concepts on tables rather than grids- check out this blog post if you’d like to know more. We found that this scaled well and accommodated the additional building blocks we’ve introduced over the years. You could connect data in different tables by using a lookup column, which enabled many powerful use cases for our makers.

However, lookup columns had some limitations, such as only allowing editing on one side of the relationship and requiring a reverse lookup formula to see connected rows on the other side. These limitations created less flexibility for makers and presented us with an opportunity to do more.

As part of one of our quarterly hackathons, a few Codans tackled this opportunity and prototyped an improved version of our connected data model. My team iterated on the model and refined the implementation, gathering helpful feedback along the way from new users, some of our largest customers, and all of you here in our community.

After lots of hard work, we’re thrilled to be launching linked relations today, bringing you a simpler and improved way to connect your data in Coda.

18 Likes

Nice, need to rethink Coda again, which is always a good thing to do!

1 Like

Thank you @Ramesh_Nagarajan :raised_hands: !

My curiosity is satisfied :grin: !

I’m thrilled it’s finally here for everybody to enjoy :grin: !

Congratulations to the whole team and thank you very very much again … for everything :tophat: !
The hard work you put into that awesome feature, but also, for listening :raised_hands: !

4 Likes

Terrific!

I imagine I’m not the only person who came from relational databases and, when I started using Coda, had assumed Coda could do this. I found so much else I liked about Coda that I worked around this absence, but I’m delighted at this news and look forward to trying this out. Thanks very much!

6 Likes

StareComputeGIF

Would be great to see some example docs!

1 Like

This is great. We’ve got power users and average users (e.g. formula users and non-formula users), and this is by far the biggest thing average users want to do that’s historically not been possible. Really appreciate the effort here, in just a couple of hours it’s already paying off!

4 Likes

I don’t have a full blown example doc on hand @Juan_David_Rey, but I have a "5 min building time " one :innocent:
(It’ll probably look a little bit better if opened in its own tab’ :blush: )

4 Likes

Wow, I can’t wait to play around with this later on this evening - PROPS Coda team!!

In addition to be a Coda junkae, I’m a “linked tables” junkae as well!

For my team at work, I created a Project and Task tacker to introduce my group to Coda (I’m trying to convince my manager to buy a license for our group!)

Today in our meeting, the person running the meeting did her usual by adding a new Task row at the bottom of the table (I have a button at the top for creating new rows w/additional options, but being at the bottom, that’s what she uses - I digress…)

Today when she added a new row, for some reason the Status column which is a lookup to another table (with multiple entries allowed) appeared to pull in ALL the options into the new row??

In the month or so of using this Doc I’ve put together, this has NEVER happened in our meetings before, until today??

So I’m posting here wondering if perhaps this exact new update is what’s causing this bug to happen now??

For some reason it’s only the Status column, not the Priority, or %Complete columns which also are lookups to other tables?
(Admittedly, the Status column allows multiple selections which is the only difference among my other lookup columns?)

If I modify the table to specify “New Task” as the default Status option, the issue goes away, but once I set that new row option to empty, it pulls in the majority (not all it seems - I’ll check later), of the Status option values?

I have to look at my table designs again to see if there’s something wonky with the way it was originally setup, but again this has been working fine for over a month++ until today’s meeting, and NOW I’m seeing this update with table relations was just added to Coda!

I’m uploading a GIF to show what’s happening, but again, this never happened w/adding new rows until today…

-Will
NewEmptyRowBug_StatusColumn

1 Like

Hi William, I would recommend you reach out to Coda support so they can help you on this specific issue. They may need to look at your doc to see what might be causing this behavior. Thanks

2 Likes

@William_Bell I took a closer look as I just worked with the team on a related change (separate from the new linked relations). I suspect you have a filter on the status column, and it doesn’t include showing rows with a blank status. Let me know if that’s correct.

When adding a row to a filtered table, we’ll attempt to apply values that meets the filter condition so the new row stays visible after you add it, even if you don’t change any values. We’ll pick the default value for the column (including blank) if it meets the filter condition, but otherwise set a value based on the filter.

For single-select columns we pick the first value that meets the filter, and for multi-select we’ll include all values.

If I understand your scenario correctly, previously when adding a new row it would have disappeared from the view if you didn’t immediately set a status. Does it meet your needs if you either set the filter to include showing blank rows, or set a default for the status column like “New task”?

3 Likes

Hi Juan

This doc gives two examples, where the link is to the same table.

The first allows the construction of parent child relationships, which can be extended to a hierarchy. (It would be great if somebody models it in the mermaid pack… just saying! :wink: )

The second shows the simple cross-referencing between rows in a table. This could probably be used in some kind of Zettlekasten implementation if one is interested.

Here is the doc with the live examples.

Regards
Rambling Pete

2 Likes

Congrats on the launch!
Being part of the beta was a pleasant experience, especially seeing how the PM team actively sought out, and adjusted the product, according to our feedback - leading to a useful and balanced final outcome. well done !

5 Likes

I’ve got a question!

It this any different than manually creating a “lookup” (relation now) column with a formula that is table.filter(linkedcolumn=thisrow)???

I mean, apart from changing name and auto-setting the formula, is there anything new?

1 Like

The main thing that is new is that we now support editing values in those columns.

4 Likes

Nice. I’ve setup a table with meeting notes, one row per meeting and I used to reference it in another table via a formula:
[DB Reunions APP].filter([Actions APP]=thisRow).BulletedList()
The nice thing about it is that with the modifier .BulletedList(), clicking on an item would open it with a single click.

With the new Linked relation, I have to click twice. Is there an option to make it behave like with the formula above?