Zammad 3.5.0 & 3.4.1

Β· We are pleased to release Zammad 3.5. This is also a Security-Release.

We always receive plenty of valuable suggestions and ideas on how to further improve Zammad (truly appreciated!). So here we go again: Zammad 3.5 offers new features that have been requested by our users for a while now: an easier process for deleting a user and the possibility of acting as both a customer and an agent. Let's dive in deeper! 🎈🎈🎈

1: πŸ” An Easier Process for Deleting a User Offers Additional Data Security

Category: Data Security

Data security is a very current topic. We have now improved the way a user account (and its information) can be deleted in Zammad to be in line with the following regulations:

  • CCPA (California)
  • DPC (India)
  • APPI (Japan)
  • OAIC (Australia)
  • PIPEDA (Canada)
  • DPA (UK)
    Easier process and more security? Sounds like a win, eh?

What exactly does it mean?

In Zammad's particular case this is related to enquiries about the deletion of a user's account and data. For example, a user might reach out to us and ask us to remove all their information from the system (which is always a bummer!).

  • So far, an agent would have had to do this manually on the Zammad console – which takes time and is annoying.
  • Now Zammad offers a new kind of permission and a special admin view that allows for the user (and their data) to be deleted directly from the ticket. Fewer clicks – less effort!

What's the benefit?

Easy: A user and all their data and tickets can now be removed from the system within seconds. If they are the only user in their organisation, the organisation will be deleted too. However, auditability is still ensured, as all ticket numbers and pseudonymised user data remain in the system. So all editing history can still be retraced.

The result? An efficient solution to a concrete problem. Which is something only few helpdesk softwares can offer. ;)

How does it work?

The process is easy. There are two possible methods:

  • via the customer sidebar – find the option called "Delete User"
  • via the profile page of the user, which can be accessed through the Search option. However, this possibility is only available to certain accounts.

Afterwards you will be forwarded to the admin area of Data Privacy. A preview will show you which tickets are about to be deleted. Besides that you can also delete the organisation if no more users are connected to it.

The (asynchronic) process of deleting the user and their data will only start after you have confirmed this action twice. Hence a deletion by accident is pretty much impossible (please don't take this as a challenge to prove us wrong!).

And that's all, folks! πŸ’ͺ

Screenshot Zammad Data security

2: πŸ”„ Agents can now also be Customer (and Vice Versa)

Category: Permissions

If you're scratching your head now wondering why or for what purpose you would need this feature – don't worry: it is not relevant for all use cases. But for teams and organisations who use Zammad to administrate their own internal enquiries as well as customer tickets it is a big deal.

What exactly does it mean?

Until now Zammad was based on the concept that every user has one role. The role defines what the user can do and which menus and overviews they can access in the Zammad web surface.

  • Agents take care of tickets, which means they complete tasks such as sending emails from the company address and taking care of requests within their scope of responsibility. So far agents were not able to see their own enquiries if these were being handled by another team.
  • Customers create tickets and receive special "overviews" of all the tickets they (as well as other members of their organisation) have filed.
    In the past the roles of "customer" and "agent" were mutually exclusive – that is, you couldn't be both at the same time.

Now Zammad can also reflect extensive organisational and administrative structures. The corresponding rights are very easy to grant.

What's the benefit?

The main benefit of this new feature can be easily explained in a simple example: Imagine there is an HR team and an IT team within the same company, and both are using Zammad.

  • The HR team is a customer of the IT team
  • The IT team is a customer of the HR team

Which would cause the following situations:

  • The HR team themselves cannot file any holiday requests as they are an agent in their own group, but not a customer – they cannot create any new tickets for HR.
  • The IT team cannot create any support requests as they are not a customer of IT
  • No one can access the internal articles of the other team

These restrictions are now a thing of the past, since users can be both agents and customers.

How does it work?

It's as easily said as it is done:

Go to the user management of the admin section, where you can now grant any user with both admin and customer rights. Afterwards you can decide which group(s) the respective rights are used and performed in. There – done already!

Some longtime users of Zammad, including several teams working with Zammad, have been asking to rebuild this permission structure. And thanks to our feature sponsors we have now changed the perspective and realigned structures: the City of Dornbirn Hospital and the EKHN (The Protestant Church in Hesse and Nassau). πŸŽ‰πŸŽ‰πŸŽ‰

πŸ’‘ Got a feature idea? Become a sponsor today!

Zammad is here to build a rock-solid customer service platform you can rely on. If there are things you wish Zammad could do, don't hesitate to get in touch and find out how to make your feature idea a reality.

3: Security vulnerabilities

After the major security audits of Zammad 3.3, we took the opportunity to dig in a little deeper ourselves. Thanks to additional support from the community, we’re proud to report that we’ve identified and fixed two more vulnerabilities in Zammad.

Hosted users: Your instance has been automatically updated already. No action on your part is required.

Self-hosted users: We recommend that you update your installations immediately.

The following Security Advisories have been addressed in this release.

Technical Notes (for self-hosted users and API clients)

  • It's strongly recommended to update the NGINX / Apache2 configuration according to ZAA-2020-18 Authentication bypass in SSO endpoint (CVE pending)

  • The required Ruby version was changed from 2.6.5 to 2.6.6 due to the security vulnerabilities CVE-2020-10663 and CVE-2020-10933

  • Debian 8 has reached EOL status and will no longer be provided packages for with the upcoming Zammad version 3.6

  • The SSO functionality now needs to be activated via Admin -> Security -> Third-party Applications -> Authentication via SSO

  • The add and delete endpoints of the REST API for tags and links have changed


All improvements can be found in the changelog.

Download Zammad 3.5.0

Changelog (2020-09-22)

Source code

Download Zammad 3.4.1

Changelog (2020-09-22)

Source code



Information about upgrading a Zammad installation can be found here:

Your Zammad team!

Together we turn your customers into fans.
Start free trial!
All releases and news directly in your inbox.
Subscribe to the newsletter