Every Notification Event in Znuny — ticket created, escalation warning, out-of-office reminder, all of them — renders its own HTML body. Admins who want a different look almost always end up editing each Notification Event individually, one HTML block at a time. There's a setting that skips that entirely: it swaps the wrapper around every notification e-mail at once.

Meet NotificationEmailDefaultTemplate

A plain-language guide to the Ticket::Frontend::MenuModule settings that control the action buttons agents see inside a ticket — no Perl required.

Closed tickets that suddenly reopen. State changes with no incoming message. Follow-up notifications are firing for no apparent reason. If you've seen this in Znuny and couldn't find the cause, the culprit might not be a misconfiguration or a PostMaster Filter rule — it could be an emoji.

Hidden Jewels in Znuny's Frontend: The Art of Ellipses and Configuration

In the world of ticketing systems, clarity and brevity are everything. Znuny quietly excels at this—especially in how it handles long strings in the frontend. Ever noticed how customer info, dynamic fields, or agent lists get gracefully truncated with ellipses (...)?

One System, Many Senders: Introducing Outbound Email Profiles in Znuny 7.3

If your organization uses Znuny with multiple sender addresses — think support@, sales@, noreply@ — you've probably run into a familiar challenge: all outgoing emails go through a single, shared mail configuration. That works fine when everyone sends the same way. But in reality, different teams, domains, or compliance requirements often call for different transport settings, credentials, or even entirely different sending methods.

Znuny 7.3 solves this cleanly with Outbound Email Profiles without require 3rd party add-ons.

Recovering from Procmail misconfigurations and spool file buildup is simple with Znuny and formail.

In a perfect world, incoming emails flow seamlessly into your Znuny ticketing system and are processed without delay. But in reality, even a small misconfiguration — especially when direct delivery is done via procmail — can quietly derail your mail intake.

Instead of creating tickets, Znuny's expected mail accumulates messages in the local spool file (e.g., /var/spool/mail/znuny). No alerts. No tickets. Just a growing backlog of unprocessed mail.

Managing change requests can feel like herding cats — multiple stakeholders, shifting priorities, and the constant risk of something slipping through the cracks. That’s where a well‑designed workflow becomes your secret weapon. In this guide, we’ll take a clean, visual BPMN process map and bring it to life inside Znuny, the open‑source ticketing powerhouse. You’ll see exactly how to turn decision points into automated transitions, keep every step accountable, and make sure no request dies in someone’s inbox. By the end, you’ll have a repeatable, auditable process that your team can follow without missing a beat.

Default Znuny Cron Maintenance Tasks

Cron Maintenance Tasks carry the weight of system health and relevant maintenance tasks. By stating and modifying these settings according to your needs, tasks such as unlocking tickets after a timeout can be handled seamlessly, enabling smooth collaboration and improved customer service.

Billing customers can be a daunting task, especially when you’re dealing with individual service requests. By adding billing codes to our requests using queue preferences, and leveraging generic interface, you can automatically send information to another system for billing.

Like with every other application, it's essential to know how your Znuny instance is doing. Besides the technical health of the server that your Linux administrators should be aware of, there are more things to check for when running a Znuny instance.
We use Icinga2 to monitor our infrastructure, internal development server, and hosted Znuny instances. There are many other monitoring systems like Nagios, CheckMK, etc. It does not matter which one you use, but it matters that you use one.