# Import Organizations: IDs do not start with ID 2 when imported using CSV
**URL:** https://community.zammad.org/t/import-organizations-ids-do-not-start-with-id-2-when-imported-using-csv/13871
**Category:** Technical assistance
**Created:** [April 2, 2024, 10:16am UTC](https://community.zammad.org/t/import-organizations-ids-do-not-start-with-id-2-when-imported-using-csv/13871 "2024-04-02T10:16:45Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@skip](https://community.zammad.org/u/skip)
#### Post date: [April 2, 2024, 10:16am UTC](https://community.zammad.org/t/import-organizations-ids-do-not-start-with-id-2-when-imported-using-csv/13871/1 "2024-04-02T10:16:46Z")
### Infos:
- Used Zammad version: 6.2.0-1709709730.4ab26fc3.jammy
- Used Zammad installation type: pacakge
- Operating system: Ubuntu 22.04
- Browser + version: 124.0.1 (64-bit)
### Expected behavior:
- Import Organizations from CSV and have the first new organization start from `ID 2` since `Zammad Foundation` has `ID 1`
### Actual behavior:
- Import CSV and the first non-zammad-foundation-organization has `ID =! 2`
### Steps to reproduce the behavior:
- Set up new Zammad instance, go to Organizations - Import - Import using CSV file or CSV in the input window
- Fail some imports
- Succeed with an import
- ID is not `2`
---
### Author:  [@skip](https://community.zammad.org/u/skip)
#### Post date: [April 2, 2024, 12:14pm UTC](https://community.zammad.org/t/import-organizations-ids-do-not-start-with-id-2-when-imported-using-csv/13871/2 "2024-04-02T12:14:55Z")
Looks like I made some mistakes in my previous message.
I attempted to reinstall my server, and now my first ID is 77.
Here’s what happened:
```
Set up the server.
Imported Organizations (failed due to a missing object attribute).
Attempted to import Organizations again (failed because the users were missing).
Successfully imported sanitized Organizations.
```
Now, the first ID (after Zammad Foundation) is 77.
At this point, I suspect that failing an import is causing IDs to be _burned_.
In my opinion, burning IDs is not what I would expect with a failed import, since the system prompts for a _real import_ when everything is fine.
Shall I file a bug report on GitHub for this?
Thanks,
Skip
---
### Author:  [@MrGeneration](https://community.zammad.org/u/MrGeneration)
#### Post date: [April 2, 2024, 12:34pm UTC](https://community.zammad.org/t/import-organizations-ids-do-not-start-with-id-2-when-imported-using-csv/13871/3 "2024-04-02T12:34:48Z")
While the increment shouldn’t be gone in my opinion, I don’t think this is a bug.
It’s an ID. It’s a counter. It doesn’t matter for your organization if the ID is 2 or 3201010.
It has zero performance implications as well.
---
### Author:  [@skip](https://community.zammad.org/u/skip)
#### Post date: [April 2, 2024, 1:21pm UTC](https://community.zammad.org/t/import-organizations-ids-do-not-start-with-id-2-when-imported-using-csv/13871/4 "2024-04-02T13:21:45Z")
I agree that burning through IDs does not have performance issues on Zammad, not sure where a possible performance issue was mentioned and that what is happening does not sound like expected behaviour.
> It’s an ID. It’s a counter. It doesn’t matter for your organization if the ID is 2 or 3201010.
I might have to disagree here, since “ID” and “counter” are related concepts but serve different purposes.
In Zammad IDs are used to establish relationships between tables, like in workflows, triggers, and other functions.
While a counter is a mechanism used to generate unique, sequential numeric values for a specific column in a database table.
IDs and counters are not the _same thing_ although it often happens that counters are associated with primary keys or ID columns to automatically generate consecutive numeric values _as new records are inserted into the table_, but the counter value increments should increment each time a _new record is added_, ensuring that each record receives a unique and sequentially increasing identifier. Which also in this case is not happening since the ID is being increased even when _no data_ is being inserted.
So, if it not a bug, then it might be worth to mention this _unexpected_ behavior in the documentation.
---
### Author:  [@MrGeneration](https://community.zammad.org/u/MrGeneration)
#### Post date: [April 2, 2024, 1:27pm UTC](https://community.zammad.org/t/import-organizations-ids-do-not-start-with-id-2-when-imported-using-csv/13871/5 "2024-04-02T13:27:14Z")
> [@skip](#):
>
> - Used Zammad version: 6.2.0-1709709730.4ab26fc3.jammy
> - Used Zammad installation type: pacakge
> - Operating system: Debian 12
btw why do you have a Jammy package installed on a Debian 12 host…?
That might cause issues as well.
---
### Author:  [@skip](https://community.zammad.org/u/skip)
#### Post date: [April 2, 2024, 1:29pm UTC](https://community.zammad.org/t/import-organizations-ids-do-not-start-with-id-2-when-imported-using-csv/13871/6 "2024-04-02T13:29:23Z")
Thanks for pointing that out, no, I have moved to Ubuntu 22.04
Let me correct my first post
---
### Author:  [@skip](https://community.zammad.org/u/skip)
#### Post date: [April 3, 2024, 6:44pm UTC](https://community.zammad.org/t/import-organizations-ids-do-not-start-with-id-2-when-imported-using-csv/13871/7 "2024-04-03T18:44:08Z")
I just noticed that if one uses the API to import e.g. roles and it fails, the ID is not _burned_, this only happens when one uses the Zammad import function
Still feels like a bug to me 😅
---
### Author:  [@MrGeneration](https://community.zammad.org/u/MrGeneration)
#### Post date: [April 3, 2024, 9:50pm UTC](https://community.zammad.org/t/import-organizations-ids-do-not-start-with-id-2-when-imported-using-csv/13871/8 "2024-04-03T21:50:09Z")
Then open a report on [GitHub - zammad/zammad: Zammad is a web based open source helpdesk/customer support system](https://github.com/zammad/zammad/) .
---
### Author:  [@system](https://community.zammad.org/u/system)
#### Post date: [March 29, 2025, 9:50pm UTC](https://community.zammad.org/t/import-organizations-ids-do-not-start-with-id-2-when-imported-using-csv/13871/9 "2025-03-29T21:50:15Z")
This topic was automatically closed 360 days after the last reply. New replies are no longer allowed.