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.

Resource settings are similar to group settings:

• General
• Permissions
• Memberships
• Notifications
• Working hours

• Group Name: Resource name
• Email: Email address(es) of the resource. Here, one or more semicolon-separated email addresses can be stored for the notification. Additionally, the first address will be used to send emails from tickets in this resource, if in the configuration Send emails is stored that the sender addresses of the resources should be used.
• Parent Resource: Selection of a resource for grouping
• Delete orders: allows a resource member with write permission to delete an order
• Change user: allows a resource member with write permission to change the user
• Use stopwatch: each editing step can be automatically recorded with their time duration. The time between opening a ticket in the ticket details view and closing the details view counts as a processing.
  • Important: The editing user must be a member of the resource!
  • In the ticket history, an entry is automatically made with the ticket action "Use stopwatch" and the duration (fields "From" and "To"). The following options are available
    • Never: The stopwatch is not used
    • On demand and with delay (1 minute): Each detail view will be logged. The detail view must have been open for at least 1 minute.
    • On demand and immediately: Each time the detail view is exited, a box asks if the processing time should be saved. The time spent counts immediately from opening the detail view.
    • Always and with delay (1 minute): Each detail view is logged. The detail view must have been open for at least 1 minute.
    • Always and immediately: Each detail view is logged immediately with time spent.
• Hourly rate: Cost per hour for editing a ticket. Also check the billing of costs.
• Escalation to: Resource for automatic escalation after escalation time has been exceeded. The escalation time is automatically calculated from the number of working hours assigned to the priority of the ticket and the stored working time of the resource per day.

The type of membership of users to a resource determines whether the user has read and/or write access. This is determined by the corresponding buttons:

• - Add resource membership with write permission.
• - Add resource membership with read permission.

Members can receive notifications when certain ticket actions occur that affect a resource. The following options are available for this purpose:

• Add attachments of jobs to emails: In addition to the email, sends any attachments of the ticket.
• Enable ticket change notifications for members: Enables resource notifications for members who have the type Resource enabled in their notification settings. These notifications are triggered when any significant changes are made to tickets in the resource, specifically: authorization, email received, reactivation, user comments, and if emails could not be delivered.

The times entered here are used to calculate escalation time. When a job is authorized from a dispatcher to a resource, the escalation time begins to run at that time.

Example: If an escalation time of 20 hours is set for the priority, the ticket will automatically escalate 20 working hours after it is authorized to an escalation resource.

By default, the working hours are Monday to Friday from 8:00am to 5:00pm.

Note: A detailed example can be found in the escalation explanation.