When Numbers Are Assigned
A reference is allocated when the record is created. Not on approval, not on issue, not the first time somebody prints it.
Where to find it
Architect Panel → Data:
- Record Numbering — the counters and their current position
- Trash — where deleted records go — their numbers are not reused
Why at creation
Because everything that happens to a record afterwards needs something to refer to it by. An audit entry, a note, a linked document and an email to a customer all want a reference, and a record that has not got one yet forces every one of those to fall back to the internal ID.
Allocating later also creates an awkward window in which two people are looking at the same record and describing it differently.
Drafts consume numbers
This is the direct trade-off. A draft that is abandoned has already taken a number, and that number stays taken.
The alternative — allocating on approval — means the record is unreferenceable for as long as it is in progress, which is usually the period when people most need to discuss it. Consuming a number is the cheaper cost, but it is worth knowing about if your process creates many speculative records.
Deleted records keep their numbers
Deletion is a soft delete: the record moves to Trash and remains recoverable, so its reference must stay reserved. Reusing it would mean a restored record and a new one both claiming the same reference.
Imports
Imported records normally arrive carrying their own historical references, and those should be preserved — a customer's old invoice number does not become a different number because you changed system.
Afterwards, move the counter forwards past the highest imported value. If the import ends at 4,120 and the counter is still at 1, the next new record collides with an imported one. This is the single most common numbering mistake at go-live, and it surfaces weeks later when somebody notices two invoices with one number.
Check the counter after every bulk load
Not just the first. A second import from a different source can push the highest value up again.
References are not a security control
A sequential reference is guessable, so it must not be the only thing standing between somebody and a record. Access is enforced by security groups and row-level permissions; the reference is a label, not a key.
Worked example
A business migrating from a legacy system imports 4,120 invoices with their original numbers, then sets the counter's next value to 4,121. The first invoice raised in the new system is 4,121, so the series is continuous and no customer sees a number they have seen before. A later import of 300 credit notes prompts the same check against the credit note scheme.
Recommendations
- Preserve historical references on import.
- Advance the counter past the highest imported value, every time.
- Expect drafts to consume numbers and do not treat it as a fault.
- Never rely on a reference for access control.