Title: Sub-admin for organizations
Usecase environment:
- average concurrent agent count - 100
- average tickets a day? over 1000
- what roles/people are involved - admin, agents
What is the idea or pain point:
- de-centralize user management, text-module management, tags managements, etc for large Zammad installations with lots of services.
- at the moment i can only assign whole-installation admin privileges so the it staff is a bottleneck for first level tasks like editing a text-module, adding a tag, disable a user. it’d help to manage more complex installations.
Expectation (not solution):
- the possibility to have power users of single organizations to manage few things like text modules, user role assignments, tags creations.
4 Likes
Hello @Filippoc
thanks for your inquiry. It is an interesting functionality which is not easy to implement “logically”.
From my point of view, the main problem here is, which assignments (e.g. groups or text modules) belong to an organization?
Should it also be possible to assign two identical e.g. groups or text modules to two organizations? If yes, what do you do in case someone edits the group of the (it causes confusion). Or what happens if the group name is already used by another organization.
In short: there are many logical problems.
Idea: A (logically) much simpler idea could be the following: What if you could split organizations to their own Zammad instances and connect them to each other (with field mapping etc.). This way you could transfer tickets from organization 1 to organization 2 for further processing.
Any opinions on that?
That’s an interesting take that wouldn’t affect the whole software logic!
A cluster logic applied to zammad instances.
Could this be something handled as a channel to manage tickets to/from other instances or an integration?
