Unique Counter to avoid duplicates

Ask for Help
1

Hi, I have messaged on this a few times now, just reaching out to see if either something has been released by Glide or if anyone else has found an easy way to this without having to use an API as that is my next solution.

I need to create unique ID (counters) for when we create projects, events, users, employees, companies, etc… We tried using the rolloup (MAX) and match (NEXT) logic, however, when we have multiple users (most cases) you get into a race condition, where if multiple people open up the form they will all receive the same ID and we end up with duplicates. Especially bad when we are trying to generate PO and invoice numbers

What we then did was to add a counter in the users profile, and increment that at time of submit, worked fine, or so we thought, over the periods of about 3 months of usage, we came across a duplicate, when we investigated further we found another 700 duplicates out of 13,000 invoices generated. The issue is that these invoices were never billed/sent to the clients for payment, we now have a lot of explaining to do with our own client.

Not sure what happened here, if it was that the same user opened up multiple windows (laptop, desktop, tablet, phone, etc…) or there was some other glitch, but its a major issue.

I am sure others are also doing invoices and have to create unique invoice numbers, how are you doing it. It needs to be an atomic operation of giving you an ID and incrementing immediately, I am surprised that it has not been implemented yet.

My next solution is to create an API for unique counter, where I start a new counter and I am returned a countername and the counter, and after that each time I want a unique ID I just make a call with the countername, it gives me the next number and increments the counter to ensure it never gives out the same value more then once. Just seem a bit of an overkill for something basic/core.

Any ideas ?

2

One way is to delegate the counter to a third party like Make/ Zapier… an action would trigger a webhook to Make and in the end you write the result back to your database

3

Yes, we can, but trigging hook costs more than one update, because one for trig and another one to call Glide API(for return response).
Instead call api can return response which don’t cost update.

1 Like
4

Hi,

Are you referring to the “FETCH JSON” under DATA and APIs ?

5

FETCH JSON alredy gone

6

I’m new to API’s and make/zappier. Can’t get this to work yet. Does anyone have a detailed example/template for making atomic increment via zappier or make?

7

Using Make, you would just maintain a counter in a Data Store. So the process would be something like:

  • Webhook to Make (needs to include the source Row RowID)
  • Read current counter value from Data Store
  • Increment counter by 1
  • API call back to Glide to update row with counter value
  • Save new counter value in Data Store
8

Is this the process you mean? If yes, would you know the cause of this error?

image
image2277×712 90.8 KB

9

Well, it’s pretty obvious. A webhook should be the first module in a scenario. If you are trying to follow what I described, you should have a HTTP module there, not a webhook.

1 Like
10

I think I got a stupid simple solution for this, as follows:

Create Table with rowid’s, in that table:

  • Joined list column of all those rowid’s of different rows
  • Split column that splits previous joined list
  • Find element index column, that looks through the lookup and finds the rowid of current row, that gives an index result.

I haven’t tested it extensively, but seems to be working perfectly fine now. I’m very curious if this could be THE solution for an atomic incrementing number, without the need or cost for webhooks/api’s/make.

Scherm­afbeelding 2025-12-19 om 16.01.04
Scherm­afbeelding 2025-12-19 om 16.01.041297×1014 147 KB

11

The Joined List following by a Split is unnecessary. A Lookup will directly give you an array with a single column instead of two columns.

It’s not atomic. If two users add a row to your table above at the very same time, they will both get the same index number of 13 until each new row syncs across to the other user device. For one user the index will stay as 13, while for the other user the index will change from 13 to 14 if their row ends up after the other user’s row. The index is a dynamic value calculated directly on each user’s device based on the data that is available at that exact moment. There is also the case if a previous row is deleted. Then the index will change for each subsequent row. Also, if row owners are factored in, then the index will only count for the rows the user has access to, so multiple users would have duplicate indexes.

2 Likes
12

On big table the lookup limits at 100 rows, a joined list with split text not. That’s why I used those 2 columns.

And you’re correct, I’ve used the wrong word with atomic increment, because if row deleted indeed all the indexes change.

The sync on big tables between phones Is really fast in my experience, so maybe with a delay of 3 sec until user sees number, this is enough. and maybe even write it so it is atomic, but haven’t tested this theory.

So maybe this is only good if you need an incrementing number for each row, but variable.
you’re also correct for row owners.

You’ve proven this method fails on multiple aspects of normal atomic increments, but I still think in some use cases this method can solve some problems. I hope so…

Like how I’ve used it for navigating to the next row detail screen based on the current detail screen. Maybe you have a simpler way for this, I’d like to hear, cuz this is not most beautiful, but fast and stable.

1 Like
13

No, I think that’s about the most efficient way to get a row number or index.

2 Likes