Infos:
- Used Zammad version: 6.4.0-1731355516.8030396c.bookworm
- Used Zammad installation type: package
- Operating system: Debian 6.1.99-1
Expected behavior:
I’m trying to manage agent communication within Zammad in an organized way. Agents are divided into different departments, which I’ve separated into groups. Each department uses its own channel within Zammad. Tickets are confidential within each group, and collaboration between groups should only happen when explicitly required for a specific ticket. This would be up to the agents of the original department to decide.
Here’s the challenge: since Zammad doesn’t allow assigning a ticket to multiple groups, I’m unsure how to facilitate cross-group collaboration. For example:
The “KB” group uses one channel, and the “IT” group uses another.
Occasionally, KB may need IT’s assistance on a ticket (or vice versa). In these cases, both groups should be able to collaborate on the ticket by forwarding it or temporarily granting access, so they can work together before responding to the customer.
What I’ve tried so far:
Mentions: This approach misses the point because:
- You cannot mention an entire group.
- As far as I understand, the mentioned entity must already have access to the ticket before they can be mentioned.
Collaboration groups using tags: The idea was to assign a tag for each department, and depending on the tag combination, a trigger would assign the ticket to a suitable collaboration group. While this sounded promising initially, I realized this approach would become unmanageable:
- The number of triggers required would grow exponentially with each additional department, making it unsustainable as the Zammad instance scales to cover more departments.
Splitting the ticket: To do this, I placed both departments within a shared organization (KB Org & IT Org) and had the agent splitting the ticket act as the customer. However, this method led to a lot of chaos:
- It introduces complexity and confusion for the departments.
- Additionally, I don’t see how this approach could work if, for example, three or more departments need to collaborate on a single ticket. Splitting tickets repeatedly would only add more layers of confusion.
Given these constraints, how can I configure Zammad to allow efficient collaboration between groups while maintaining ticket confidentiality and avoiding excessive complexity?
I’m hoping someone has already successfully tackled this problem, or that the solution is very obvious and I am just blind to it… 