From Ticket Chaos to Process Clarity: How Znuny Turns Insurance Follow-Ups into a Governed Workflow

One of the most valuable uses of workflow automation is not just speed, but clarity.

In a recent Znuny process design for motor insurance follow-ups, the focus was on improving how external insurer questions are managed within an active customer case. Instead of handling these clarifications manually across disconnected updates, the process structures them as linked follow-up tickets tied directly to the original case.

That creates a much cleaner operating model. The main case remains the central business record, while insurer-specific follow-ups are managed in their own controlled workflow. As responses come in, updates are automatically reflected back into the parent case, giving teams better visibility without adding administrative effort.

Znuny 7.3 is available today. This release focuses on two themes that matter most to IT teams running production service desks: security and daily efficiency. Here’s what’s new.

Keeping an eye on what's happening inside your help desk shouldn't require guesswork. Znuny-PrometheusExporter makes real-time monitoring easy by exposing vital Znuny metrics in Prometheus format, enabling seamless, actionable insights in your existing monitoring stack—at no cost.

The package can be installed directly through the Znuny Package Manager from the Open Source repository, and the source code is available at GitHub.

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 (...)?

Single Sign-On has long been a requirement for enterprise deployments of Znuny. Until now, making it work meant configuring an external Apache module — typically mod_auth_mellon or mod_auth_kerb — correctly wiring it to your Identity Provider, and then connecting the result to Znuny's auth pipeline. It worked, but the setup was sometimes fragile, hard to document, and entirely outside Znuny itself.

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.

You are probably waiting for the release of Znuny 7.3 – we are as well. During the development phase of 7.3, we made an important decision to improve this and all future releases: we changed the timeline for when our add-ons for new versions become available.

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.