regarding number increment
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎07-08-2025 10:24 PM
Whenever I am inserting new record the number is increasing but without saving it is also incrementing and one more issue when iam created record with import sets if inc number is already created when iam inserting new record then it shows again that number in number field
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎07-08-2025 10:39 PM
Hi @sivavalluri , please find the solution below.
Please mark it as accepted and helpful if you find it useful.
Issue: Auto-generated Number Increments Without Saving & Duplicate Numbers via Import Set
Hi all,
I came across two issues while working with auto-generated numbers in ServiceNow:
1. Number Increments Even When Record Isn't Saved
Behavior:
When I create a new record (e.g., Incident), the number field (like INC0010001) is generated even before I save it. If I cancel or validation fails, the number still increments. The next record gets INC0010002, and so on — leaving gaps.
Explanation:
This is expected behavior in ServiceNow. The system uses the sys_number table to maintain number sequences. The number is reserved before the record is saved. Even if the save fails or is canceled, the number is still consumed and not reused.
Conclusion:
You might see gaps in numbering, but this is by design to ensure uniqueness and avoid conflicts — especially in concurrent environments.
2. Duplicate Numbers When Importing Records via Import Set
Issue:
While importing records using Import Sets, I noticed that if a number like INC0010003 was already assigned, a new record inserted via the transform map could get assigned the same number — causing duplication.
Root Cause:
This typically happens when the number field is mapped directly in the transform map, and coalesce is misconfigured or missing.
Best Practices:
Avoid mapping the number field in the transform map unless you intend to update existing records.
Let ServiceNow auto-generate the number via the standard sequence logic.
If you must pass a custom number, add a check in the transform script to ensure it's unique:
if (target.number && new GlideRecord('incident').get('number', target.number)) { // Duplicate number found — reset to allow auto-generation target.number = ''; }
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎07-08-2025 10:41 PM
Hello!
Your number field issue has two parts: the number incrementing without saving is normal behavior, as the system reserves the next available ID when a new record form opens. The more critical problem, where import sets cause existing numbers to reappear for new records, is likely because your import set is either directly mapping the number field (overriding auto-generation) or failing to update the system's "next number" counter after import. The primary solution is to remove the number field mapping from your import set's transform map, allowing the system to auto-generate unique IDs, or if mapping is necessary, manually adjust the system's number counter after the import.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎07-08-2025 10:53 PM
yes it's a platform behavior, even if you open a new record and don't save, it will increase
Set this property "glide.itil.assign.number.on.insert" -> true
If your import set is creating a new record then after you enable the above property it should work fine.
If my response helped please mark it correct and close the thread so that it benefits future readers.
Ankur
✨ Certified Technical Architect || ✨ 9x ServiceNow MVP || ✨ ServiceNow Community Leader
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎07-09-2025 04:03 AM - edited ‎07-09-2025 04:04 AM
@Ankur Bawiskar glide.itil.assign.number.on.insert set to true the number field is not populated i tried this already