Thanks for the feedback! We’ll think about it.

Auto Number, as it exists today, was designed to let you assign unique identifiers to records, without ever reusing the same identifier.

There are two workarounds that can get you close to what you want:

1. 
   

   To start at an arbitrary number, create a formula field that adds the starting number to the auto number field. e.g. to start at 100, the formula would be: 99 + {Name of Auto Number Field}. You can hide the auto number field and just look at the formula field.

   
   


2. 
   

   To get rid of gaps, convert the auto number field to a regular number field, then back to auto number. But be careful with this! Since it renumbers the records, you’ll lose the old numbers.

   
   

This thread touches on a relatively irrelevant but persistent issue that I"m sure plagues other users as well. When I or a colleague is at the very end of a table entering or editing data it is very difficult --or impossible-- to avoid hitting Enter automatically when done with entering data. As you know, this creates a blank row below and the column in autnonumber displays the next number.

My tables often populate with records created via Zapier. This means that after a record is edited, info is added, or anything like that, the new row that’s created by this automatic Enter hitting will be blank and will remain blank. Because I do use the autonumber to identify records, I cann’t reset it as you suggest in #2. I have to live with a blank record or learn to not worry that sometimes there are gaps in the numbering. There is, however, the big risk of deleting records and not having the help of autonumber to help notice.

It sounds like your problem is with the behavior of ghost rows specifically (“ghost rows” being the rows created with a new autonumber but without any data). We might just change the behavior of ghost rows rather than overhaul the entire autonumber behavior. Do you have any specific requests for how you’d like the autonumber to work with regard to ghost rows?

As a side note: most developer-oriented databases (i.e. MySQL, PostGres, etc.) have behavior similar to ours, where the autonumber doesn’t fill in the gaps for deleted rows. More consumer-oriented database products (e.g. Filemaker, Zoho Creator) generally work this way as well. This allows each row, even deleted ones, to always have a unique autonumber.

Katherine, thanks for your reply. I would expect these ghost rows to “give back” their number to the counter. I wouldn’t consider a row that had data that then at some point was deleted a ghost row, but I don’t know if it is a distinction the system could make. I wouldn’t expect/want the autonumbering to fill the blanks created by user-deleted rows as I can see issues arising from there – mainly renumbering items where the autonumber is used as an ID or key. However, maybe there is a way to avoid adding an autonumber to a row until at least a character or even a space is typed or data is pasted? That I would endorse.

I might suggest two auto-numbers. An absolute that behaves as-is, and and an “intuitive” (or whatever; maybe “human”) that discounts ghost rows, and potentially deleted rows within a given time-frame. AKA, rows deleted well after creation would not “give back” their number, but rows deleted within a given period after creation would.

I would really like to be able to get a random number - like a GUID or UUID, but with a number of digits users could specify for their purposes. I can see why incremental auto-numbers are helpful in many cases; however, when I only add a handful of new records to a particular table once a month, and it’s helpful to be able to refer to the record by this number, a bunch of non-sequential numbers is a lot easier to work with (and not get mixed up). Maybe I’m alone on this one, but at least with the auto-numbers and the entered numbers fields it would be great to specify digits and not just decimal places. 1-9 do not sort nicely with two-digit numbers in most programs I work with, and Airtable removes the 0 if you try to enter 01 etc.

Considering this topic was started > 1 year ago, I am curious if there have been any Airtable system changes or any other clever suggestions for handling the arbitrary starting number and/or mitigating the ghost rows numbering issue.

At the moment, I am trying to devise a simple ID column that starts at 2 and every following row is always n + 1. Starting at 2 was actually a mistake in the numbering system of my use case (which I am now deeply regretting btw, haha), that cannot be changed any longer.

I was even hoping for a way to calculate the MAX() number of a given column and use a function to figure out the next number in the series, but couldn’t figure it out. I guess similar to a database trigger where the trigger decides what the next value in the autonumber will be, in this case, MAX() of the column + 1. Thanks!

So I had to do a really awful workaround for this.

I created a second table with auto-numbering and then associated each record in the first table to a record in the new and then made a lookup column to bring in the auto-number. While that seems like a lot of extra work, I set up a Zapier ZAP to make a new record on the new table for every new record in the first table and then associate it.

Yeah thats a lot of steps to just fix the fact that I can’t autonumber off of a start # or for only certain record types…

I’m curious what your zapier setup looks like - i thought about going this route, but haven’t dug in enough on zapier to figure it out.

Replying here though the request is not quite the same.

I would like an auto-number based on a single select field. In other words each selection is its own list. My example would be from our Destiny Search Project project. We have a volunteers table that also allows us to single select if the are searchers, DSP Admins, or Volunteer staff. We could us a seperate table but it would be extra steps when running an operation.

An autonumber that could have leading numbers would be awesome. I admit I can create this using a series of IF statements to add the leading zeros, but a built in feature with autonumber would be really nice. Especially if you need a large number.

Is there any news on how Autonumber works / or doesn’t work with “ghost rows”?

Ghost rows are an extremely annoying Airtable behavior. Quite a few of our collaborators keep creating blank rows by accidents (it’s happened to me too). That always throws our numbering system off. I only want Autonumbers assigned to actual records not erroneously created rows.

Right now I keep converting the Autonumber field to a text field and back to Autonumber. A simple reset button in the Autonumber field would do the trick.

@Markus_Wernig,

One recommendation I can give is to use permissions to prevent collaborators form being able to add or delete records without forms. It would be much easier to ensure the record being created is intentional when a form is used.

Obviously, there are downsides to using a form. If you need to input many records, you can unlock the permissions temporarily and then put them back in place when you are done.

Hope this helps while Airtable works on improving Autonumber and implementing an iterative operator. Both are sorely needed.

There’s one big issue that’s been missing in this discussion – which is to update auto-number values whenever a user drags records up and down in a table.

For some reason, currently, when a user drags records up and down in a view, Airtable does not see that activity as an sort of material change to a record. This is problematic, because I can’t even build API automation fire webhooks whenever a record’s relative position in a view changes. Because of this limitation, I can’t figure out how to programmatically update auto-numbering whenever a user performs these operations.

This is frustrating, to say the least.

In short, I’d like an auto-number option that:

1. Has no numerical “gaps” between records


2. Whenever a user drags records up and down in a view, then auto-number values automatically update to reflect their relative position.

This is a dead topic, but regardless, what you’re asking for will never be addressed by Airtable imo. Due to reasons that I can only speculate about, though they are surely numerous from Airtable’s perspective, starting with the fact that this is a non-issue which was meant to be left to the community to “solve” via the Scripting app.

Yeah, JavaScript is fast enough to handle state-level HTML monitoring and does so already. But adding one more function reliant on ultra-low latency to a codebase that might have already taken some hostages in protest of Airtable’s scalability? The won’t do it, especially since that functionality requires minimal fiddling with the Scripting app to reproduce (the row recalculation, that is, drag event listeners aren’t so simple because of the platform restrictions imposed as part of a pretty straightforward security policy).

The relative position of a record in a view is not a part of the record’s data. Records can have different positions in different views.