Findings that become tickets

Wegweiser tells you what is wrong with an estate. Your helpdesk is where work actually gets done. Until now the journey between the two was a person reading one screen and typing into another.

Wegweiser now connects to Zammad.

You will find it under Integrations in the sidebar, which is now an index of everything Wegweiser connects to rather than a shortcut to whichever integration was built first. That was a real problem and not a cosmetic one: the nav item said Integrations and opened the Kaseya VSA 10 wizard, so a second integration had nowhere to appear. Both are there now, each showing whether it is connected and what it has actually done, alongside what we are looking at next.

It reads your organisation list first

You already have a source of truth. For a Zammad shop, that is the organisation list in your helpdesk, and those "customers" are as likely to be your own branches as external clients. Retyping a hundred and fifty of them into a second system is not a migration, it is a reason to abandon the second system.

So the first thing the connector does is offer to read them. Connect, pick which Zammad group tickets should land in, and Wegweiser shows you what is there: this instance has 150 organisations. Tick the ones that should exist in Wegweiser and they are created and linked. Run it again later and the ones already linked are shown as linked, never duplicated.

Nothing is written back at this point. Importing an organisation gives you visibility. Putting its findings into a live helpdesk queue is a separate decision, and it is off until you make it - per organisation, so you can watch one client's estate for a month before anything of theirs reaches your queue.

Four things earn a ticket

A ticket is a unit of work for a human being. That is the only test we applied, and it rules out most of what Wegweiser produces. A score that moved three points is true, interesting, and not work. Putting it in your queue is how an integration gets switched off in week two.

A honey account was used. The strongest signal the product has, and the only one that is a fact rather than a read on evidence. Somebody authenticated as an account that exists only to never be used. High priority, and the ticket carries the event itself.

A drive is reporting its own failure. S.M.A.R.T. predicted failure, exhausted spare blocks, reallocated sectors. Bounded work, a real deadline, and the kind of ticket a client remembers you for.

An unsuppressed malware or IOC detection. If you have already told Wegweiser a detection is expected on a machine, it never becomes a ticket. Telling your helpdesk anyway would be ignoring you more expensively.

A device crossed down through the health threshold. Note crossed - this fires on the crossing, not on being below the line. A machine that has sat at 55 for three months stays quiet, because a rule on the state would open a ticket every night for ever. And the ticket names which checks moved, because a score is an average and "58" is not something anybody can work on.

And a great deal that does not

The restraint is the feature. Everything here was written to answer "how would this annoy somebody enough that they switch it off":

One open ticket per device per condition. A drive that has been failing for a week is one piece of work, not seven. Updates append to the same ticket.

Updates only when there is something new. A condition that is still true with the same evidence has already been said. A ticket with forty identical updates is one nobody reads to the bottom of.

It never reopens what you closed. If a technician closes our ticket, that is them telling us they are done, and we never touch it again. Before every update and every close, we check whether somebody has finished with it.

A ceiling per organisation per run. A bad patch or an over-matching rule hits every machine at once. That has to be a handful of tickets and a note, never four hundred.

A dry run before anything is written. You can see exactly what a run would do to your helpdesk before it does it.

What it will not do

It will not write a health score into Zammad. That is not a gap we plan to close: Zammad has no device or asset object at all, so there is nowhere for a per-device score to live. Scores, history and the analysis stay in Wegweiser, and the ticket links back to the device.

That turned out to be worth stating plainly rather than quietly engineering around. Every ticket is written to be worked from the ticket alone - what happened, the evidence, and what to do next - with the link there for the detail rather than for the basics.

One bug worth telling you about

The first version of the malware condition read the detection list straight out of the scan data. The first time we ran it against a real estate it produced a ticket reading "50 malware detections" directly above the analysis saying score 100, verdict CLEAN.

All fifty were the scanner matching its own compiled rule file. Wegweiser's scan analysis already knows to discard those, along with detections you have suppressed and unsanctioned-software findings that are a conversation rather than an incident. Reading the raw data skipped every one of those judgements and kept only the parts that looked alarming.

It is fixed, and the lesson is now written into the code where the next integration will read it: do not re-derive a verdict the analysis has already reached. Fifty imaginary malware tickets on day one is not a rough edge, it is the end of the integration.