Groups are a form of access authorization and a way to mimic how larger companies organize themselves. Agents who are members of a group can see its content and perform certain actions. This makes it possible to restrict who has access to what information. Groups are created and managed by admins.
Groups are a form of access authorization. They allow you to determine what specific agents are allowed to do with a ticket.
Let's say your company uses Zammad for both Sales and Customer Support. There are ten different agents spread across two teams who handle countless tickets every day.
Without groups, all ten agents could see (and respond to) every ticket, regardless of which department it is for. This doesn't have to be problematic per se, but it does lead to unnecessary clutter in the overviews . (A more critical example would be if employees can see the messages that should go to the management and thus see, for example, how much the colleagues in the Sales team earn...)
However, if each agent is assigned to a specific group, then they would only ever see the tickets that belong to their respective group.
The assignment to a group is done by an administrator. Each agent can always check which team he is in - in the notifications section of the user settings:
Anyone who belongs to more than one group can move a ticket from one group to another.
Tree Structure for Groups
Starting from Zammad 6.2, groups now support the creation of sub-groups up to two levels. This enhancement is a response to the increasing complexity that comes with the growth of a company. With more departments and teams, Zammad has been made more flexible to accommodate these changes. Users can now establish group trees that reflect their organizational structure, providing a visual map that simplifies the management of interconnected elements.
More information can be found in our Documentation for agents and the Admin documentation.