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 organization for every single site.
There is the requirement that every organization only sees their group
To do so, there are 450 agent roles, every role has full control on either a site group or a district group.
This ensure that the web notification (the one with the bird) for new tickets is only received by agents that have the role for the dedicated group.
This way, if the agent changes sites, the assigned roles are changed and the permissions permeate through all the system.
The Customer in this case is assigned a single group using core workflows which is their site or district group. I was able to export/import workflows successfully, which is nice.
A following challenge is that within a district (collection of sites) different agents might be responsible for different sites part of the district, therefore 1 site = 1 group, 1 group access = 1 role in conclusion 450 sites = 450 roles.
The manageability is given by the fact that no manual management is done in Zammad and everything is managed through API calls (or rails console) with JSON or CSV files.
Update a user? Change the CSV file and upload/update user data
Update permissions? Change the CSV file and upload/update roles
and so on
This makes it also possible to track changes (the files are on GIT) and to replicate in case of a disaster (backup gone, all dead? set up systems with ansible, reimport all files from git, done. old tickets are gone, but settings, permissions, groups, users, etc… are all available again)
I would love to simplify the agent thing, but the web notification in Zammad itself is an issue because it is not configurable who receives the notification based on what. A “is part of organization” would solve that, since in that case I could use organization as filter for overviews and workflows as I am doing already for groups assignments.
Best,
Skip