Does multiple help desks need multiple virtual machines?

[Travis]

Infos:

• Used Zammad version: 6.2.0-1712728678.1fb595f2.bookworm
• Used Zammad installation type: package
• Operating system: Debian 12
• Browser + version:

This is more of a “how should I be doing this?” question than a problem, maybe it’s what the “Organization” feature is for, I’m unsure.

Long story short, my organization has loved using Zammad so far for their IT help, and want me to move “all of the other helps” onto it. Maintenance department stuff, requests for the mechanics or fleet managers, requests for the social media and marketing people, etc.

I was doing something like this previously with Spiceworks, I had one Active Directory domain where the people from those departments would be “admins” of their respective help desk, but they want me to put everyone on Zammad and I’m not sure the right way to do this.

Would I create multiple “Organizations”, and name them things like “IT Department” and “Maintenance Department” and “Marketing Department”, and then do something like promote people from maintenance / marketing / etc. to be agents for that organization, if that’s even a thing?

Would I do this by having multiple incoming email addresses for tickets, each with a different “group”? (can that even work if all of my users are logging in from the same LDAP source, no matter which “help desk” they are assigned to)

Is this a job for just going from one VM running Zammad to four VMs running Zammad? (I technically could do this, but the other three help desks are at about two to three tickets per year usage volume, so I don’t want to create a ton of VMs if I don’t have to)

[Sal]

If I understand correctly, you can do this with one Zammad instance. You will need to utilize Groups, Roles, and custom Overviews. I don’t think Zammad can have admins per department (Group/Roles) though.

[skip]

Hello,

I am doing something similar within our organization.
You can read about it here:

Export/Import Overviews using the rails console

Hi! Thanks for the questions. The issue is pretty interesting. There is a public organization with 450 sites. Single sites have a group and two or more sites can be part of a district and have a common group. Every site is treated independently as it’s own entity and agents are responsible for around 12 sites each and there is a backup agent which is not always the same for the 12 sites. Which means around 24 mixed sites per agent. There is a group for every site or district. There is an o…

What I did was create a group for every organization, agent roles for every organization and with core workflows I direct certain users to the correct group to make sure that the agent and customer only see the tickets that concerns them.

Within the overviews everything is also filtered by organization.

My suggestion is to set up a separate machine just to try out the configurations.

Best,
Skip

[YetAnotherGerrit]

Groups are there to organize your agents into teams. Organizations are to group your customers.

[Travis]

Thanks for the input everyone, I set up a test machine that I think might be doing what I want, but I might be doing it in a stupid way. (and I’m fine with that)

All of my tickets come in technically via email (forms on a WordPress installation gather the data I need and email it to an email address) and I have triggers set to look for [IT] or [Maintenance] or [Marketing] in the title of the ticket (the WordPress form will send the email with one of those things in the subject line), and if that’s there it changes the “Group” on the ticket to either “IT” or “Maintenance”, etc. and then the active directory users who would be helping with those types of tickets are agents in those groups.

I think this should work for a single active directory environment where every user is a “customer” for every possible type of ticket, but some of the people who are customers of one kind of ticket are also “agents” for different kinds of tickets.

Question about triggers I’m using in case anyone has a good answer for this.

Is the way I should be going this is…

IF
Title contains [Maintenance]
THEN
Set group to Maintenance

…or should I be doing instead…

IF
Title contains [Maintenance]
AND
Group is not Maintenance
THEN
Set group to Maintenance

…because I’m not sure with the first one if I’m going to create tons of extra workload as the trigger infinitely and repeatedly changes the ticket group from Maintenance to Maintenance, or if it’s smart enough to know “I already did this”

[Sal]

I’ve been using Zammad for some time now, so I haven’t invested time into workflows which was added after I started using it. I believe you can do this using them as @skip suggested.

I use Email Filters for stuff like this as it applies to the email before creating the ticket.

Triggers are great for managing changes to current tickets.

Email Filters are great for addressing emails that come in before creating the ticket.

I use an email filter to check for a specific subject and if it exists, assign it to a specific group and category.

I believe that you can make agents, agents for specific tickets and customers for others. I think this would be done in the user profile. I haven’t done this myself though.

[Travis]

Ah ok, yes, that looks like a better way to do that than with a trigger, thank you.

I’ve never touched workflows or templates, mostly because I’m unaware “what even is a work flow and what would I do with it” but it’s probably not a feature I “need”, because the email from the form I’m using it getting the logged in user and a hostname and a clickable link to remote control that computer, etc.