# Human-readable Row ID
**URL:** https://community.glideapps.com/t/human-readable-row-id/81703
**Category:** Community Resources
**Created:** [May 4, 2025, 4:46pm UTC](https://community.glideapps.com/t/human-readable-row-id/81703 "2025-05-04T16:46:17Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@nathanaelb](https://community.glideapps.com/u/nathanaelb)
#### Post date: [May 4, 2025, 4:46pm UTC](https://community.glideapps.com/t/human-readable-row-id/81703/1 "2025-05-04T16:46:17Z")
The idea is to manually create a `text column` alongside the `Row ID column` that will house a unique human-readable row ID. Once set and used, the text in this column is to never be changed, as if it were not mutable (though technically it is).
**When would human-readable row IDs NOT be used**
For relations. For relations, it’s always preferable to use the `Row ID column`, which is both basic and non-mutable.
**When could human-readable row IDs be used**
To set conditions for visibility conditions, filters and actions in the layout and workflow editors. The associated `Row ID` could be used instead (and it would make the setup more robust), but using a `Row ID` can make the initial setup cumbersome because the developer might have to switch back and forth to the data editor, and it can make troubleshooting more complicated. Using the human-readable row ID, especially if it is easy to remember, can make it easier to set up the conditions.
Maybe Mark (@V88) can share more about his approach to human-readable row IDs.
* * *
In response to [Best Practice for Creating Relations](https://community.glideapps.com/t/best-practice-for-creating-relations/81603/6)
@Robert_Petitto
---
### Author:  [@HTML](https://community.glideapps.com/u/HTML)
#### Post date: [May 4, 2025, 5:02pm UTC](https://community.glideapps.com/t/human-readable-row-id/81703/2 "2025-05-04T17:02:52Z")
Add an incrementing row number each time a new row is added. Writing the value as the current max row plus one is not only human-readable, but also makes it much easier to locate that row during troubleshooting. In many cases, you don’t even need a row ID anymore, which saves a column full of unnecessary characters. For even better traceability, you might prefix the number with the table name.
---
### Author:  [@nathanaelb](https://community.glideapps.com/u/nathanaelb)
#### Post date: [May 4, 2025, 5:36pm UTC](https://community.glideapps.com/t/human-readable-row-id/81703/3 "2025-05-04T17:36:53Z")
> [@HTML](#):
>
> Writing the value as the current max row plus one
This method is fine but I personally prefer using the method using `Find element index`. It explicitly goes through the steps of what’s happening under the hood.
In the first case with `Increment`, a row is added, then an increment action is triggered, and finally the row index is set. The increment action being separate from the table is particularly inelegant.
In the second case with `Find element index`, a row is added and the row index is set. In the same breath. The second method is shorter and really, when a row is added its index is known that very moment, any additional external resource or action is unnecessary. I don’t know what the term in the industry for this is, but I would call it “technical bloat”. The increment action happens outside of the database (data editor) and inside the workflows editor, it make things that much more “unclean”.
In my opinion 🙂
---
### Author:  [@nathanaelb](https://community.glideapps.com/u/nathanaelb)
#### Post date: [May 4, 2025, 5:42pm UTC](https://community.glideapps.com/t/human-readable-row-id/81703/4 "2025-05-04T17:42:25Z")
> [@HTML](#):
>
> In many cases, you don’t even need a row ID anymore
Which
1. basic (non-computed),
2. immutable (cannot be changed willingly or unwillingly)
3. and native column (native to Glide Tables)
would you then use to create `relations`?
> [@HTML](#):
>
> which saves a column full of unnecessary characters
Columns in the data editor can be hidden, this feature could come in handy should you want to not display the `Row ID column`.
---
### Author:  [@HTML](https://community.glideapps.com/u/HTML)
#### Post date: [May 4, 2025, 5:48pm UTC](https://community.glideapps.com/t/human-readable-row-id/81703/5 "2025-05-04T17:48:07Z")
You can’t use the `findIndex` method for creating row IDs — every time you delete a row, all IDs will change. Use a logic column to generate the next row ID value and write the “Simple Row ID” column of the newly added row.
---
### Author:  [@MaximeBaker](https://community.glideapps.com/u/MaximeBaker)
#### Post date: [May 4, 2025, 11:32pm UTC](https://community.glideapps.com/t/human-readable-row-id/81703/6 "2025-05-04T23:32:33Z")
I know @John_Romano did something interesting. But I don’t remember where he talked about that. I think it was in Slack.
---
### Author:  [@Darren\_Murphy](https://community.glideapps.com/u/Darren_Murphy)
#### Post date: [May 5, 2025, 3:13am UTC](https://community.glideapps.com/t/human-readable-row-id/81703/7 "2025-05-05T03:13:48Z")
> [@HTML](#):
>
> Add an incrementing row number each time a new row is added. Writing the value as the current max row plus one is not only human-readable, but also makes it much easier to locate that row during troubleshooting. In many cases, you don’t even need a row ID anymore, which saves a column full of unnecessary characters. For even better traceability, you might prefix the number with the table name.
The only issue with this method is that it is subject to concurrency issues, which means it is possible to end up with duplicate row numbers. If uniqueness is critical, then you have two options:
- native RowID column
- delegate assignment of Row identifiers to an external 3rd party
No other method guarantees uniqueness.
---
### Author:  [@HTML](https://community.glideapps.com/u/HTML)
#### Post date: [May 5, 2025, 3:23am UTC](https://community.glideapps.com/t/human-readable-row-id/81703/8 "2025-05-05T03:23:02Z")
Do you think Glide doesn’t have a mechanism to prevent that? It should queue row additions; otherwise, they’ll run into problems with many other actions as well.
---
### Author:  [@Darren\_Murphy](https://community.glideapps.com/u/Darren_Murphy)
#### Post date: [May 5, 2025, 3:29am UTC](https://community.glideapps.com/t/human-readable-row-id/81703/9 "2025-05-05T03:29:28Z")
I know it doesn’t. Glide actions such as Add Row and Increment are not atomic, and never have been. At least not with user initiated actions. Server-side workflows are relatively new, but from what I’ve seen so far I believe that they could be subject to the same concurrency issues.
> [@new\_button Updates to the Glide + Make integration](https://community.glideapps.com/t/updates-to-the-glide-make-integration/67979/16):
>
> Increment is not an atomic operation. The increment happens on the client, and the result is sent to the server. For atomic increment, you should use Call API with a service like Upstash that offers serverless redis (a database with first-class support for atomic increment). You can get a good result this way! We did it for PGA when they needed a distributed counter for their grandstands. We’d like to offer atomic increment in Glide but it’s not a top request from customers yet.
---
### Author:  [@HTML](https://community.glideapps.com/u/HTML)
#### Post date: [May 5, 2025, 3:32am UTC](https://community.glideapps.com/t/human-readable-row-id/81703/10 "2025-05-05T03:32:28Z")
I didn’t suggest incrementing action; I suggested using a pre-calculated value for the next row, so it already exists before the row is added.
---
### Author:  [@Darren\_Murphy](https://community.glideapps.com/u/Darren_Murphy)
#### Post date: [May 5, 2025, 3:37am UTC](https://community.glideapps.com/t/human-readable-row-id/81703/11 "2025-05-05T03:37:54Z")
Same same. Unless ownership of your “pre-calculated value” is delegated to a 3rd party, it’s possible to arrive with duplicates.
Imagine two users adding a row at exactly the same time. Where does each user get that pre-calculated value from? And how do you ensure that they aren’t both using the same pre-calculated value?
---
### Author:  [@HTML](https://community.glideapps.com/u/HTML)
#### Post date: [May 5, 2025, 3:39am UTC](https://community.glideapps.com/t/human-readable-row-id/81703/12 "2025-05-05T03:39:53Z")
That should be solved by add row queue. Like in mySQL, there is no way to duplicate.
---
### Author:  [@Darren\_Murphy](https://community.glideapps.com/u/Darren_Murphy)
#### Post date: [May 5, 2025, 3:43am UTC](https://community.glideapps.com/t/human-readable-row-id/81703/13 "2025-05-05T03:43:41Z")
Except is isn’t. Because each add row happens on each users local device, and is then synced with the Glide back end.
This discussion has been had several times over the years in this community, and the behaviour is well understood.
The method you have suggested can work to a certain point. If there are a relatively small number of users, then the risk of duplicates is small. But it exists.
---
### Author:  [@HTML](https://community.glideapps.com/u/HTML)
#### Post date: [May 5, 2025, 3:45am UTC](https://community.glideapps.com/t/human-readable-row-id/81703/14 "2025-05-05T03:45:31Z")
Oh, it’s not even sending the row addition request to the server? You must be kidding me. In that case, I give up—LOL. Anyway, who would seriously use Glide for a high-traffic app?
---
### Author:  [@HTML](https://community.glideapps.com/u/HTML)
#### Post date: [May 5, 2025, 3:55am UTC](https://community.glideapps.com/t/human-readable-row-id/81703/15 "2025-05-05T03:55:10Z")
so, You can add the user’s row number to the ID to avoid that extreme case. 😅
---
### Author:  [@Darren\_Murphy](https://community.glideapps.com/u/Darren_Murphy)
#### Post date: [May 5, 2025, 4:02am UTC](https://community.glideapps.com/t/human-readable-row-id/81703/16 "2025-05-05T04:02:38Z")
> [@HTML](#):
>
> Anyway, who would seriously use Glide for a high-traffic app?
The PGA Golf Tour, apparently 🤷♂️
---
### Author:  [@Krivo](https://community.glideapps.com/u/Krivo)
#### Post date: [May 5, 2025, 7:09am UTC](https://community.glideapps.com/t/human-readable-row-id/81703/17 "2025-05-05T07:09:38Z")
@nathanaelb I don’t really understand why you want to use human-readable row ids instead of using other parameter. Could you elaborate a bit on the need😎
---
### Author:  [@nathanaelb](https://community.glideapps.com/u/nathanaelb)
#### Post date: [May 5, 2025, 8:15am UTC](https://community.glideapps.com/t/human-readable-row-id/81703/18 "2025-05-05T08:15:53Z")
> [@Darren\_Murphy](#):
>
> If uniqueness is critical, then you have two options:
>
> - native RowID column
> - delegate assignment of Row identifiers to an external 3rd party
>
> No other method guarantees uniqueness.
I think we’ve gotten used to the `Row ID` and `Relation` columns, but I wonder if Glide could do without. The concepts and use cases would stay of course, but the columns, or at least how they are represented in a table, would go.
1. With this discussion, I realize that I use Row IDs for relations only, due to their uniqueness. The `Row ID` column would be there under the hood but unbeknownst to the developer.
2. The `Relation` column is like not other in that it doesn’t house any data, it’s simply an indicator column. The column is very practical, but it’s not as natural as the others.
So maybe something could be done with those two columns to simplify the building experience 🤔
---
### Author:  [@HTML](https://community.glideapps.com/u/HTML)
#### Post date: [May 5, 2025, 1:29pm UTC](https://community.glideapps.com/t/human-readable-row-id/81703/19 "2025-05-05T13:29:09Z")
When it comes to relating data, I don’t think anything is simpler or clearer than a unique row ID. The row ID could be a simple incremented row number, like in MySQL, if Glide supported generating it that way. But then you face the challenge of identifying the table and app—assuming all your data is in one file. They do offer an alternative, like a lookup column. Or if you want to go full PRO, don’t use rows at all—store all your data in JSON and work with it using the JavaScript column.
---
### Author:  [@nathanaelb](https://community.glideapps.com/u/nathanaelb)
#### Post date: [May 5, 2025, 1:44pm UTC](https://community.glideapps.com/t/human-readable-row-id/81703/20 "2025-05-05T13:44:50Z")
> [@HTML](#):
>
> don’t use rows at all—store all your data in JSON and work with it using the JavaScript column
I’m not convinced this would have anything to do with going “full pro”. It seems difficult to work with JSON strings and JavaScript code rather than tables of data. And Glide is a nocode platform, and in this context working with tables in the data editor seems a more natural experience than JSON and JavaScript.
[Next page](https://community.glideapps.com/t/human-readable-row-id/81703.md?page=2)