Resources are a central part of the organizational structure in i-net HelpDesk. They allow the automatic or manual distribution of tickets according to application areas. Requests must be assigned to a resource. The program does not allow an end user/customer to assign a new request directly to a resource.

Assigning a ticket to a resource is possible as follows:

• manually by a Dispatcher from a request (that is: a ticket without a resource),
• indirectly via:
  • the category to which a resource can be assigned,
  • the User Class, a field of the user master data, which can also cause the resource to be set,
• automatically when receiving an email,
• manual forwarding by a resource member from another resource.

The membership in a resource allows a user to read or write all tickets in that resource.

Resources can be grouped into main and sub resources for better overview. Every user who is a member of a resource is granted access to the tickets of this resource. Depending on the permissions, a distinction can be made between read and write access.

For the access permission to tickets of a sub-resource, the following applies: the read and write permissions of the main resource are used if the sub-resource does not have its own members. Illustrated by the example main-resource A with the sub-resources A1, A2 and A3:

• Situation 1: User is member of a sub-resource, e.g. A1, but not member of main resource A.
  • Result: Access to tickets in sub-resource A1. There is no access to tickets in the main resource A and the other sub-resources A2 and A3.
• Situation 2: User is a member of main resource A as well as A1, but not A2 or A3. In A1 and A3 memberships of supporters (with read/write access) are stored, A2 has no own members.
  • Result: All tickets in the main resource A as well as in the sub-resources A1 and A2 are accessible. Access to A and A1 exists because the user is directly included as a member. In A2 there is access because A2 does not define its own members and therefore the members of A are inherited to A2. In A3 there is no access because own memberships were defined for A3 and therefore no inheritance takes place.

Thus, constellations can be created where new users only have to be assigned to the main resource and get access to the sub-resources via inheritance, or where this is not the case if only certain users are allowed to access a sub-resource.

Important: Inheritance of memberships from a main resource to a sub-resource only refers to ticket access, not to any permissions of the resource.

Note: The grouping behavior related to ticket access has changed with version 20.4 and differs from the behavior of older versions.