Hi,
I’m looking for an API-based open-source ticketing system like Zammad for my company. but when I checked the GitHub repository, there are 142 open issues labeled as confirmed bugs.
I was wondering if anyone here uses Zammad in production? any problem with it? and what’s wrong with those issues?
Thanks,
Dawood
Hi Dawood,
we are preatty new to Zammad and are using it in production since a few weeks. We do not have any problems with Zammad. Each problem we had was caused by other systems (f.e. imap communication was blocked by MS Exchange).
I never had a better ticket system, because Zammad is so flexible in configuration and so simple and fast to use.
I think the cause for the amount of open issues at GitHub could be, that a lot of users report issues but not so many contribute on the code. You should remember that Zammad is a company the needs to earn money, so they need to prioritice paid work.
So I would not panic cause of the amount of open issues, because… hey, you are getting a great ticket system for free! 
And if you want to be sure that issues are solved fast, then you allways have the option to pay for support.
Best Regards,
Bernhard
And don’t forget: They are also helping here in the community.
We can second that. Previously we have used otrs and kix.
We have been testing zammad since version 2 or so and ran the system in “staging mode”. The final decision to switch was when the feature / integration of the knowledge base was released.
Although some features could be improved. We have been able to work around most limitations. The only feature currently missing is “dependent objects” otherwise everything is running smoothly.
We have switched to production a few weeks ago and never looked back.
BR wucherpfennig
It is not uncommon to have bugs in any project but you can just track them yourself 
(Open source).
I have been happy with Zammad.
We chose Zammad because of its better mobile/user GUI interface but OSTicket was a close second. Custom Objects was a hudge benfit in our review.
Note: since our choice of Zammad, OSTicket have now annonced a GUI Public Roadmap.
We are happy with our pick of Zammad and do not see us changing ticket system anytime soon.
Hope this helps.
Stay Safe.
Hey @Dawoodkhorsandi,
we’re using zammad in production since 2017 (Version 2.2) and we’re pretty happy with it.
I can strongly endorse everything the other guys said.
cheers
While those are the number of open bugs, we also regulary close a lot of bugs.
That’s a process that takes time. Don’t just look on open stuff, but also on historic closed stuff.
I think that helps to get a better image.
We are using it in production since one month now and are pretty happy. We migrated about 12k tickets + 40k articles via Zammad REST-API into a self hosted Zammad 4.0 instance (we were coming from Freshdesk).
Feedback from our team is quite good so far. The custom overviews are great.
Of course there are always some features you wished that would work differently. Some things are not consistent. But so far we managed to get most of it working for us or found workarounds for rare cases. I think it is normal for such complex systems, that you need to tweak them over a few month while working with it. Maybe we find the time to contribute something back or pay Zammad guys if stuff hurts too much
Thanks everyone - your kind words encourage us to continue giving our best 
there’s always room for improvements but we’re working hard to minimise it. There are some interesting month ahead. Stay tuned!
@Dawoodkhorsandi - you’re right about the labeled bugs and there’s not much to add to what @bernhardk already wrote except that you can follow our progress more closely here: Pulse · zammad/zammad · GitHub .
As you can see we’ve closed more than 50 issues in the last month alone. We prioritise by highest impact to the majority of the userbase. That means that sometimes enhancements or features get prioritised over bugs.
@wucherpfennig - we’re actively working on it 
More to come
Thanks everyone for sharing your experiences and helping us out. As I mentioned we want to use an API-based ticketing system, to be consistent with the UI of the whole product.
So we will try the Zammad API to see if it fits our needs or not.
Best Regards,
Dawood
If you like to contribute something back to the zammad team and the community, you might think about to share your scripts with some details of the progress to migrate from fresh desk to zammad. It might help other for similar tasks.
Hey there,
we just migrated from freshdesk to zammad and what can I say: we love it. It took me one weekend to install, configure and migrate our complete setup to zammad.
Due to the change we earned so many functionalities, especially one thing I want to share with you.
We used freshdesk (and now zammad) for sales and support requests. With freshdesk it was not easy to keep the overview of sales requests within different stages. With zammad it was so easy: we added a new “select” object to the ticket, called it “sales process” and then added different views like “stage 1”, “stage 2” etc. Wow, now everything is clear and obvious…
I can recommend zammad to everybody. It is absolutely a great solution.
Best regards
Christoph from SeaTable
We basically did it with our own connector software. Maybe we will provide steps for Zammad API in the future to allow others to do the same. Basically we used the XML-Backup-Export of Freshdesk and pumped it to Zammad API. Only thing which got lost where attachments, as they are not in the export… I mean we didn’t put much effort in it, as we don’t care. We just need the old (closed) tickets to look stuff in the near future.
One suggestion for zammad team to think about: It would be nice if it would be possible to enable/disable import_mode in zammad UI… nobody likes to use rails-console Remember: import_mode=true is needed set created_at and other timestamp fields from outside. If you don’t do this, timestamps will set by zammad to be “now”.
If zammad wants to attract more people switching from different solutions you should make importing easier. Maybe even provide a CSV-Import for tickets and articles. For us it was ok, because we are dealing with APIs every day, but for others it could be challenging.
Here are the main requests and logics to give you an idea:
1. Create tickets
POST /api/v1/tickets/
{
"fd_ticket": ${identifier!},
"title": "${name!?json_string}",
"state_id": <#if status! == "Closed">4<#elseif status! == "Open">2<#else>3</#if>,
"group": "<#if group_id_name!?contains('Sales')>Sales<#else>Support</#if>",
"customer_id": "guess:${helpdeskticket_requesterid_email!}",
"created_at": "${created_at!?keep_before('+')}.000Z",
"article": {
"subject": "${name!?json_string}",
"body": "${helpdeskticket_descriptionhtml!?json_string}",
"from": "${helpdeskticket_requesterid_email!}",
"to": "support@example.com",
"content_type": "text/html",
"type": "<#if status! == "Closed">email<#else>email</#if>",
"created_at": "${created_at!?keep_before('+')}.000Z",
"internal": false
}
}
2. Add articles / responses to the ticket
POST /api/v1/ticket_articles/
{
"ticket_id": ${parent_zammad_id!},
"from": "${email_from!}",
"to": "${email_to!}",
"cc": "",
"subject": "",
"body": "${helpdesknote_bodyhtml!?json_string}",
"content_type": "text/html",
"type": "<#if note_source_name! == "reply">email<#else>note</#if>",
"internal": ${helpdesknote_private!},
"created_at": "${created_at!?keep_before('+')}.000Z",
"time_unit": null
}
Maybe HTTP request already help somebody, because it took some time to get them right. The scripting language you see is called Freemarker and used in our solution to do if-else logic and stuff. Just ignore them or get an idea of what we did.
While I get your point I want to react to this real quick:
Having a button to enable or disable import_mode is a potential dangerous operation.
The import_mode disables some checks to allow specific situations you’d need during importing existing data. You usually do this once only.
Apart from the ton of settings you’d have in UI, I think it’s a bad idea that may break instances for users that are not too sure what this option actually does.
Ok, I understand that philosophy, but I would just encourage to think about ways to make importing historical data / soft-migrations easier (instead of big-bang-once migrations).
We would have preferred rolling out zammad in parallel with our existing solution and continuously pump in new data. Even migrating other tools later would be possible then without a “import_mode=true downtime”)
Maybe allowing to specify override timestamps and disable triggers per API-request would be sufficient to allow that.
Maybe think about it like this: you could also consider that it could make external import tools easier. It would allow importing historical data from external tools without telling the Zammad user to enable some import_mode via command line. It is just about enabling non-technical people. I think the technical person who installs Zammad (command line) is not necessarily the same as the one migrating tickets. The latter could be a business / support person who knows all about tickets. Anyway, all is good for us now 
Just wanted to share “first impression kind of feedback”.
Just a heads up to all the Freshdesk users that want to test/migrate to Zammad: There will be an official Freshdesk migrator with the upcoming release 4.1 
It’s only a couple of weeks from now so you might want to wait if you haven’t migrated yet. It will be easy as 123: Just add your URL and API token and Zammad does the rest. You can keep an eye on this issue: Freshdesk · Issue #865 · zammad/zammad · GitHub
This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.