Chips versus text when adding row

6

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. :slight_smile:

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:

  1. Pass by ID: Resulted in i-g1JAtWCKpI (A valid chip/reference).
  2. 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()
  )
)