I have come across this issue many times but I cannot figure out what is the root cause behind it - since sometime it works perfectly.
I have a company table with all my companies. The “Company Name” comes from a select list tied to a another table called “Company Name Table”.
Now when someone wants to log meeting notes I use a Company Helper Table. So in the meeting notes they click a button that opens up the helper table and they fill in all of the fields. Then they hit another button which copies all the info from the helper table to the company table.
So far so good. I know this structure is used by many. However, the problem I am facing is that when I go to the Company table and search for the company it doesn’t show up because the name is added but is not a selectable Chip. So in the company table I have to select the new company name to turn it into a chip. When I do this, it is listed in the Company Name Table so it did get properly added.
Do I need to create a separate button to first add it to the Company Name Table so this is done before I add it? Or is there a way to tell it to add it as a chip in the first place?
Thanks in advance on this one as it drives my nuts!
Thanks
1 Like
Not sure if that will work but did you check if all select-columns are column that are actually related to the source table - not only a formula with options from the source-table? I noticed, having a formula that refers to that source table to make different options available in that select, often isn’t enough.
1 Like
Interesting question. Will double check that and report back. It was built in my early Coda days so anything is possible.
Unfortunately it is set up properly. My current hypothesis is that when I copy from the helper table to the company table it adds the value to the company table before it is a selectable item from the name table. So this is why, afterwards I can select the correct chip from the drop down list and it is already there. So if no one has anymore ideas I many adjust it so when I click the add button it will first add the name to the name table and then add it to company table
1 Like
I tested it and it does work creating a two step button process and then creating a button to push the other buttons in the correct order. A bit burdensome but it is a solution.
1 Like
I asked my CFL-aware agent to take a stab at this issue, and here’s what it came up with. I’ll let you be the judge. 
Note - this agent uses Coda MCP to create a document and the components necessary to verify that its answers work.
Walkthrough: Solving the “Chips vs Text” Issue in Coda
I have researched the user’s issue and verified the root cause and solution using both smartCFL patterns and direct testing via the Coda MCP.
The Core Finding: Strings vs. Row Objects
Coda is strictly typed. A Relation Column expects a Row Object (internally referenced by its rowId).
- Text Input: If you pass a string like
"Company A", Coda stores it as literal text. It may match the display name of a row, but it is not linked.
- Chip Input: If you pass a Row Reference (e.g.,
i-g1JAtWCKpI), Coda creates a “Chip” which is a live, searchable link to the original record.
Verification Results
I created a test document Chips vs Text Test and performed two AddRow operations on a Relation column:
- Pass by ID: Resulted in
i-g1JAtWCKpI (A valid chip/reference).
- Pass by Text: Resulted in
"Company A" (Disconnected text).
This confirms why the user in the community found that their companies were search-disabled until they manually turned them into chips.
The “Solid” Answer
Based on smartCFL integration patterns, the recommended solution is to use AddOrModifyRows to “resolve the chip” before adding it to the destination table.
Recommended Formula
RunActions(
[Company Name Table].AddOrModifyRows(
Name = [Helper Table].[Company Name],
Name, [Helper Table].[Company Name]
),
[Company Table].AddRow(
[Company Name],
[Company Name Table].Filter(Name = [Helper Table].[Company Name]).First()
)
)
1 Like
Hello @Chris_DeAngelis ,
I have read your your post and the replies from others and yourself.
- What I cannot figure out is why you have a (separate) company table and a company name table. If you want a column in the company table with the “chip” in it, all you have to do is add a (text) column and add the formula thisRow()
- as far as adding meeting notes to the Company table: I would create a meeting notes table, use the company name (the chip) as the Key field and show the notes as a filtered subtable in the company records. Doing it that way is common practice.
If you need help with the above, create and share a dummy doc that sort of resembles your doc and you will most likely get some really useful responses.
Greetings,
Joost
2 Likes
Excellent question. In the early days I didn’t have a CRM so I used the name base as a table for validation to use across the business in different places. Then when the CRM was created I linked to the name table. You point is valid and now the logic seems wrong. I think it is worth cleaning this up. Thank for pointing this out. As for the rest of your comments, this is what I am doing today,
Much appreciated.
1 Like
Thanks @Bill_French Problem solved. That worked. For other’s benefits let me rephrase the solution. First, Add the name to the [companyname] table. The second operation is to not add the text from the helper table into the company table (if you do this, the text wont show up as a chip even though it matches) but instead what you want to add is the [companyname] filtered to be equal to the text field you just entered as the new name in your current helper table. When you do this it passes the row reference as confirmed by Bill and it works.
Thanks everyone
2 Likes
Great to hear.
To be clear, I didn’t do anything. I tasked an Antigravity agent armed with Coda’s new MCP service, and it designed the solution and validated the advice by building a Coda doc and all example tables, running the tests, and using a browser subagent to verify it wasn’t giving bad advice.
Upon hearing about your success, the agent responded:
Yes, I certainly remember that one! It was a tricky little nuance in how Coda handles data types in actions. The core “aha moment” was realizing that RunActions() needs to be explicit about data types:
The Issue: When adding a new row via a button, passing a text string (e.g., “Acme Corp”) into a Relation column (which expects a Row object) resulted in it looking like a chip but behaving like text—or failing to link properly.
The Solution: We had to break it down into two distinct steps within the RunActions() formula:
- Create the Entity: First, add the text value to the source table (e.g., Companies) if it didn’t exist.
- Pass the Reference: Then, critically, we had to look up that newly created row to pass the actual
Row object (the “chip”) to the target table, rather than just passing the original text string again.
It’s a classic example of the difference between a “label” (text) and the “thing itself” (object reference) in Coda’s formula language. It was great to see Chris clarify that for the community!
2 Likes
