Job and Order Reference Numbers: What Should Your Business App Promise?

Give each job or order a stable reference that staff and customers can use to identify the same record. Before development, decide when the reference becomes permanent, where it must be unique, whether gaps are acceptable and what happens to imported records. A number that increases automatically does not answer all four questions.

This guide concerns operational job and order references. It does not define legally compliant invoice numbering. If a number belongs to a regulated document, obtain the applicable requirements from a qualified adviser and specify that numbering process separately.

Start with the conversation the reference supports

A useful reference lets someone say “I am calling about this order” without describing the entire transaction. Choose a format that your team can read aloud, find in search and distinguish from a customer's own purchase-order number.

Keep those two references separate. Your customer's reference may be repeated across different customers, entered incorrectly or changed at their request. That does not make it a suitable replacement for the stable identity your app needs.

Decide the uniqueness boundary explicitly: the whole business, one branch or one yearly series. If different series can contain the same short number, show enough context in search results and exports to distinguish them. A prefix is useful only when everyone receiving the reference can interpret it.

Unique does not mean gap-free

PostgreSQL's sequence documentation explains that concurrent calls to its next-value function each receive a distinct sequence value. It also warns that aborted transactions and crashes can leave gaps, and that its sequence objects cannot provide gapless sequences. This is a specific database mechanism, not a rule that every numbering scheme must behave the same way.

For an ordinary job list, decide whether uniqueness is sufficient. Do not ask a developer to remove visible gaps by renumbering existing jobs: an emailed reference would then point to a number that no longer identifies the same work.

A gap alone is not evidence that someone deleted a job. Ask how support can investigate missing references using the actual workflow history rather than guessing from the number sequence. If your business genuinely requires an unbroken series, describe why and ask for a separately designed process rather than assuming an automatic database number provides it.

Agree when a reference becomes a promise

Does a draft have a temporary label? Is the final reference assigned on creation, approval or confirmation? Write the chosen event down, and decide what customers see before it occurs.

For PostgreSQL sequence values used persistently outside the database, the documentation says to ensure the transaction containing the next-value call has committed first. The practical commissioning question is whether a reference shown in a confirmation actually belongs to a saved record. Ask the developer to demonstrate failure between saving and displaying the result.

Also define a repeated submission. The system should follow your agreed duplicate-request policy rather than create two orders merely because someone clicked again. Reference generation and duplicate-request handling are related, but they are not the same requirement.

Keep references stable through change

Agree that changing a customer's name, reassigning a job or moving it to another branch will not silently replace the reference already sent to someone. If a visible reference must change, decide how the old one still leads authorised staff to the correct record and how the change is explained.

During an import, preserve the old system's reference as a separate searchable value where needed. Plan collisions before loading records. Do not overwrite an existing job just because a different source system used the same number.

Cancelled work should have the agreed status and explanation. Recycling its reference for unrelated work can confuse someone reading an old confirmation; recommend avoiding that reuse.

A hard-to-guess reference is not access control

OWASP's IDOR prevention guidance states that access checks remain essential even with complex identifiers. Knowing a job number should not automatically entitle a person to its details.

Ask for authorised test accounts belonging to different customers. In an isolated test environment, have the developer demonstrate that changing a reference cannot expose or modify another customer's record. This is one targeted check, not a complete security assessment.

What to settle before handover

Record the format, uniqueness boundary, assignment event, gap policy, cancellation behaviour, import mapping and old-reference lookup. Then test simultaneous job creation, an abandoned save, a repeated request and an imported collision. Check that the reference is consistent in the screen, confirmation and export.

Put those outcomes into the project's acceptance criteria. When discussing a custom business app, bring example references from your current process with private information removed. The goal is a dependable way to identify work, not a decorative numbering pattern.

Sources and scope

• PostgreSQL, Sequence Manipulation Functions: https://www.postgresql.org/docs/current/functions-sequence.html
• OWASP, Insecure Direct Object Reference Prevention Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html

The sources support the specific sequence and access-control statements. Format, stability, cancellation and import rules are practical recommendations to agree for your application, not legal numbering requirements.