Photo by Enrico Mantegazza on Unsplash

and deleted items in relations

How to get rid of deleted items still living in your lookup?

4 min readMay 5, 2023


In the

community an interesting question got a smart response from Virginie. In short: how can we clean up a table that contains items removed from the lookup (or relations are they are renamed). Brian — who asked the question — also shared that his previous solution no longer worked.

[Lookup Column].ToText().Contains("Deleted Row")

The solution Virginie proposed is simple and smart. Ask if the item is from table (table name). Is that the case, keep it, if not, remove it.

Value column

We start with a small table like below that has two columns, the display column and a second column named ‘value’ . Although it looks the same, the column value only contains the text value and not the object. When you reference the value, you have no longer the @…. with all related info, but a flat text item. Since the calculation is set up and the value column is hidden, it requires no additional calculation when I reference the text value instead of the object. I’ll come back later to this.

These names come back in an other table, see below via a relation

we use the names from DB Employees in our relation

What happens when we delete one of these names: Jane.

the item Jane is removed but you can still count the letters

The ‘fromTable’ checkbox is no longer checked, but the length (thus the count of the letters of the name Jane) is still intact. The item — although removed — still seems to be present. The btnDelete relates to the described logic and thus becomes active when the item is no longer from the referenced table.

We get a double message, deleted but not yet removed.

The deleted item ‘Jane’ in light grey lives in a twilight zone and the longer the item stays there, the more likely it gets fully removed. I believe that this in-between status is practical.

However it can be confusing when you look at it first.

Putting back deleted items

In the screenshot below you see that I referenced the value to have a readable unique reference. Once I remove the chained ‘value’ the reference is still present and as such you still have — but only indirectly — access to all data related to this object.

Indirect because you have to bring back this reference into the source table not by typing in the name again nor by using the reference to the deleted item, but by what you see below.

bring back the deleted item

You put your cursor on the deleted item and the card appears. You click on Restore row and the magic happens.

Here we are: deleted but not yet removed. This logic won’t hold forever, after a certain time the items move to the

Elysium and you can no longer restore an item like this.

My name is Christiaan and I support SMB with calculations (budgets and — Human Resource — planning) and I prefer using Coda to get the job done.

I hope you enjoyed this article. If you have questions feel free to reach out. Though this article is for free, my work (including advice) won’t be, but there is always room for a chat to see what can be done. Besides you find my (for free) contributions to the Coda Community and on Twitter.

Coda comes with a set of building blocks ー like pages for infinite depth, tables that talk to each other, and buttons that take action inside or outside your doc ーso anyone can make a doc as powerful as an app (source).

Not to forget: the Coda Community provides great insights for free once you add a sample doc.



I write about how to Coda . You find blogs for beginners and experienced makers. I publish about 1 / week. Welcome!