Roles vs Groups

[mkarg]

Unfortunately the manual is ambiguous about the actual sense of roles and groups, and there is no concensus in the user base, so I'd like to kindly ask to give some comments about what the OTRS developers had in mind with roles vs groups:

* In a company there are three departments: Development, Sales and Support. Each employee works in exactly one department. There is one single queue in which all tickets live. This queue is managed (owned) by Support. There are three organizational functions to fulfil regarding tickets: First Level Support (can open tickets when customer calls in that queue), Second Level Support (can edit and close tickets in that queue) and Third Level Support (will help second level with complex requests).

What is the correct way to model this? Apparently it is wrong to model departments as "Group" instances and organizational functions as "Role" as this leads to the fact that only the queue owner (Support) can see tickets in that group.

So how to correctly model departments and organizational functions in OTRS, os "Groups" and "Roles" is apparently the wrong way?

[jojo]

already explained in german thread.

In the early years there were no Roles. Only groups for assigning permissions.

[mkarg]

already explained in german thread.

In the early years there were no Roles. Only groups for assigning permissions.

Can you please post a link to that thread? I actually cannot find where it actually explains how to model "Agent A works in Department D, and everyone in Department D acts in Role R".

[jojo]

I'm talking about your thread.

What you wan't to achieve is not possible in OTRS.

[mkarg]

I'm talking about your thread. What you wan't to achieve is not possible in OTRS.

I see and accept, but actually I wonder why the OTRS Groups GUI actually proposes to name groups as departments -- this totally confuses newbies like me, as groups are never departments following the logic behind OTRS' way to deal with groupts!?

[crythias]

Roles: a way to consistently apply multiple group permissions to Agents. In theory, if you start using Roles, you may wish to ignore direct agent-group assignment because of management overhead.

There is one single queue in which all tickets live.

Queues are [groups of] agent that can handle a particular [type of] request. Good queues: Tech, Plumbing, Maintenance. Other possibilities: Tier1, Tier2, Tier3.

What is the correct way to model this?

Depends on your view of "Correct".

*A* way to model this is to provide "Tier1" as a queue for which customers can submit tickets (Filter available new-ticket queues for Customers).
If a ticket is to be escalated, Move the ticket to Tier2, etc.

[mkarg]

Roles: a way to consistently apply multiple group permissions to Agents. In theory, if you start using Roles, you may wish to ignore direct agent-group assignment because of management overhead.

There is one single queue in which all tickets live.

Queues are [groups of] agent that can handle a particular [type of] request. Good queues: Tech, Plumbing, Maintenance. Other possibilities: Tier1, Tier2, Tier3.

What is the correct way to model this?

Depends on your view of "Correct".

*A* way to model this is to provide "Tier1" as a queue for which customers can submit tickets (Filter available new-ticket queues for Customers).
If a ticket is to be escalated, Move the ticket to Tier2, etc.

Understood. Thanks for your kind help. To sum up, I must not use OTRS Groups to model organizational departments unless all agents accessing the queues owned by that group are part of that same group. To model organizational departments an external grouping feature like LDAP has to be used, as kindly pointed out in the German forum.