So I’m aware that I can use RowID() to return the ID value within the table, but based on the return results from the API this isn’t the same as the actual row ID, it’s actually the index (at least I think so).
I need the actual “id” i.e. “i-ft58426d56a2dds” to be accessible from within the table, so that I can use it in a webhook. Is that possible?
Hi @Murray_Adcock,
no we dont expose it anywhere - are you looking to access same row every time ? you could give it a name and use that way through api - you dont need an internal row id for that.
our api to access row is https://coda.io/apis/v1beta1/docs/{docId}/tables/{tableIdOrName}/rows/{rowIdOrName}
more info here: https://coda.io/developers/apis/v1beta1#operation/upsertRows
Thank you.
Thanks, but the name is a little too tricky. There could be multiple rows with the same title at the moment, plus it’s a user editable field. Does the “name” have to be the tagged column? If not, I could just create a column with a guaranteed unique field.
To be clear, I’m looking to set up a button that links to a webhook and passes information to a third-party tool, which manipulates it and passes it back (effectively a Zapier “Zap” like interaction, but without Zapier as we don’t want to migrate to that system); I want the passed back value to go to the row on which the button was triggered. Whilst the interaction should be fairly instantaneous, we have a number of people working on this doc simultaneously, so it’s certainly possible that the tagged column get change without someone realising.
EDIT: Actually, thinking about this more closely, it’s a guarantee that we will have identical names within the data set. I’m using the table as a cross-channel content scheduler, storing everything from long-form articles to social media posts, but we have functionality where you can “push” an article to social media and use the fact that the “name” is the same to track that relationship. I’ll be able to use “name” for genuinely instant interactions, but any kind of long-form tracking requires access to the ID, so it’s a shame I can’t access it from within Coda directly.
Hi @Murray_Adcock,
Thanks for highlighting your use case. I am asking folks on the team more familiar with this area to figure out how we can help.
For now, here’s a workaround that could help. (not ideal, but may be as a stop gap measure?)
https://coda.io/developers/apis/v1beta1#operation/resolveBrowserLink to retrieve the URL for the row.Thank you.
Interesting, I was looking into ways to do this myself, though again it’s a shame it can’t be (easily) automated. I was wondering if there might be a way to resolve the link directly in a function. Will continue looking into it 
Could you use the following formula in a hidden field as your makeshift ID?
Middle(Random(false),3,16)
+1 – we integrate Coda with other 3rd party systems and want to be able to know that a Customer in QBO with ID qbo123 is the same as the row in Coda with ID coda456 so that when an update is made in one place it can be synchronized elsewhere.
It should be straightforward for y’all to provide us the canonical ID for the row from the interface and would be a huge help without having to add an additional resolution step.
This thread got bumped, so I figured I’d chime in.
I’m fairly sure that it can be done with the help of _Merge(thisRow) hidden function: it shall expose the datastore row ID. Then use RegexExtract() to get it out of the json, or use ParseJson() alternatively.
I’ll test when I get home
@Paul_Danyliuk always expanding my mind? What does merge() do?
@Johg_Ananda _Merge(object) is a hidden formula that’s mostly interesting due to the fact that it allows exposing internal Coda object structure. _Merge(whatever) + "" is an idiom to render that as JSON:
Then use e.g. RegexReplace:
thisRow.[Column 4].RegexReplace('^.*"identifier":"([^"]+)".*$', "$1")
to only extract the row ID.
Source: A somewhat of a documentation of hidden formulas [Added mechanics of nested buttons]
@Murray_Adcock Actually while doing this I figured out I could simply try thisRow + "". And voila, it does this:
and then just thisRow.[Column 6].Split("/").Last() to get the row ID. No hidden formulas required!
@Krunal_Sheth FYI
Although for everyone else’s consideration — what’s wrong with using the good old thisRow.RowID()? Except the webhook mentioned in the original post, I don’t see why RowID is not suitable for record matching.
Great workaround.
+1 for feature request of cleanly exposing the same ID that the API sees. (My use case - a button that packs the row ID into a query string to launch an outside service. CodaAPI.getRow() is expecting this ID; I know I can query a table to find a row, but I suspect that’s less performant?).
This is really critical. Our use case is the following.
Not being able to easily access the rowId is a major block for us right now. Copying the docUrl manually will be difficult with hundreds of items. Any updates on this?
The RowID(thisRow) is accessible. What I’m not sure about is the automation of a value changing. If you don’t mind creating a sample doc with some sample info that you’d need included in the URL, we can help with formulas.
@Aram_Zadikian @Nick_HE et al
The Split(thisRow + "", "/").Last() trick works perfectly for me. I’m using it all the time to expose row UID to external docs via Cross-doc to relink entities on the “frontend”.
One of the advantages of UID over RowID() is that it’s assigned on the client right away, while RowID requires a round trip to the server, and its assignment may be delayed if you’re adding lots of rows in bulk. (not that you’ll be able to access the unsaved row anyway, but still, a behavior to be aware of, especially if you’re doing linking of items by IDs and not references for some reason).
I just hope Coda doesn’t remove the + "" trick that converts various kinds of objects to strings via Javascript internally. Quite a few of the docs I built for clients now depend on this.
A more detailed write-up on retrieving and using actual row IDs (UIDs):
There are significant differences between “RowId” and a “UniqueID” of a record, and I’m concerned they’re being confused a little here. For APIs, I would think it is more relevant to be able to refer to a unique ID than it is to refer to the RowID, considering that the table can be sorted, rearranged, etc. and so change the RowID as it relates to the record itself. In some systems, the record’s unique ID is generated when the record is created, and it behaves like the unique name we should be naming our records with (but which can be difficult sometimes with things like Task Names on standard project methods), giving each record a unique identity.
I would be interested in a unique id similar to what can be generated in Excel:
=DEC2HEX(RANDBETWEEN(0, 4294967295), 8)
which results for each cell an ID similar to:
D1AE30DD
EC9C4174
D5DB6A2E
D4EF1EEC
0E44CA18
Is there a capability for something like this? @Paul_Danyliuk @Krunal_Sheth
And am I capturing your original question in what I stated above? @Murray_Adcock
I’m not sure why an extra layer is needed other than aesthetics. Just to clarify…
The UID discussed is accessible to the API. This you can see in Paul’s posts about how to retrieve it.
The RowID() is a unique value for that row and does not change. This is a more readable value for a lot of applications within the product, but can also be used as a unique value for referencing an exact row within a table. This does not change with sorting and even if you delete a row, you won’t get the same RowID with the next row added.
Perfect, thanks for that clarification!
While this workaround is perfectly stable, I think it’s safe to say that over the years many a reason to use the actual rowID have come up. Is this on the backlog? A straightforward formula would be much appreciated!
