Import Organizations: IDs do not start with ID 2 when imported using CSV


  • 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

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?


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.

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.

btw why do you have a Jammy package installed on a Debian 12 host…?
That might cause issues as well.

Thanks for pointing that out, no, I have moved to Ubuntu 22.04
Let me correct my first post

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 :sweat_smile:

Then open a report on GitHub - zammad/zammad: Zammad is a web based open source helpdesk/customer support system .