How Can We Help?

Base Concepts

The configuration of Deepser is easy and lets you use the software to manage your service in few and simple steps.
Before starting, it is important to know some base concepts to configure the system quickly.
We recommend to read very carefully this introductive guide to start taking advange of all the powerful features of this Service Desk tool!



Deepser has a modular structure. That means every item in the menu is a module.
For example, the item Service represents the module “Service” of Deepser; the item Dashboard represents the module “Dashboard”; the item Activities represents the Activities module, and so on.


If we expand the menus of the single modules we can find othe sub-items, that are not “sub-modules” of the softwatre, but specific entities to manage that module.


An exception is the item System. This item is composed by a large number of sub-menus, that are themselves specific modules for the system configuration.




Deepser allows the connection only to users recorded in its the database (to give access to a “guest user” it is possibile to configure a specific user).
The users can be manually inserted, or created from an LDAP Integration (Active Directory, OpenLDAP, etc.) or with email integration.


The users are divided by 2 main categorization:

  • Role: the role is used to define which modules can see the user and to define the user type.
    In a few words, every user has one (and only one) role and the role identifies the user type.

  • User Type: we can find 4 user types in the system: Administrator, Agent, Key-User and User. The user type is defined by the role of the user. When a user is set with a specific role, then he automatically inherit the user type for that role.
    We provide a short description of the different user types:
    • Administrator: can access all the modules, even the configuration modules.
    • Agent: can manage the records and access to the back-end, he can modify some settings like grids. He cannot access the system configurations.
    • Key User: can manage the records and access to the back-end, but he cannot modify any settings.
    • End User: can access only to the End User Portal.

Clicking on the item System > Permissions > Users we can find the grid with all the users in the system.
There are 5 grids (by default) that groups the users by the 4 user types (Administrators, Agents, Key-Users, End Users) and a fifth grid with all the users without a role.

To learn more about users configuration, please read: Users Configuration.


User Groups

Once defined the role (and so the user type), we can create infinite groups to manage the working teams.
Groups allow to define two important configurations of the system:

  • Assignment to the records: the working team of users thet must solve a request or the team that has to manage an object of the CMDB.
  • Records Permissions (Create/Read/Edit/Delete): Deepser lets you filter the permissions for different working teams inside the modules they can access (based also on the role of the users).


To learn more about groups, please read the section: Groups Configurations.


Service Module

The module called “Service” contains all the information to manage the requests in the system.
There are 2 key concepts inside the Service Module:

  • Service Types: the Types of the requests that are managed by our service. It is important to define the Service Types to better organize the work of our service.
  • Service Operations: all the records, representing the support requests, the failures, the change requests, etc. in the system.

Deepser is installed woth a set of standard Service Types, that reflects the ITIL theory:

  • Incident: the incident management process is to restore a normal service operation as quickly as possible and to minimize the impact on business operations, thus ensuring that the best possible levels of service quality and availability are maintained.
  • Request: is the process to manage the service requests, that are minor changes or information requests.
  • Problem: the term “problem” refers to the unknown cause of one or more incidents, the control of errors (a problem is an error if its cause is known and there is no workaround), to prevent errors and create workarounds.
  • Change: the addition, modification or removal of any authorized, planned, or supported service or service component that could have an effect on the services.

The default standard types don’t bind the configuration of Deepser: we can insert new Service Types to adapt the software to our organization and the services we provide.

To learn more about Service Types and their configuration, please read: Service Configuration.

As said before, the Service Operations are the real records that represent the service requests.
Every Service Operation has one Service Type well defined, so every Operation in Deepser is related to one (and only one) Service Type.
Every Service Operation contains data: the title of the request, the requester user, the due date, priority, urgency, category, etc.
We will see in the next sections the main data of the requests.

To learn more about Service Operations and their configuration, please read: Service Configuration.



Deepser allows you to confiure lists, that represent coded data in the system (typically a key-value pair).
Lists are usually displayed with select-box elements.
Talking about Service Operations, the main lists are:

  • Status: the status of the request.
  • Priority: the priority given by the working team.
  • Urgency: the urgency given by the requester user perspective.


There are other lists in the system, and all the lists are customizable (create / delete values), even if the default values are sufficient for the normal operativity of the users.

Every value in the list can belong to a value class, for example, in the list “Status” it is possible to define which values are:

  • class “Open” the request is still active and not yet terminated;
  • class “Closed” the request is terminated and there are no more actions to complete on it;
  • class “Deleted” the request has been canceled;

To learn more about lists and their configuration, please read: Lists Configuration.



Categories are a particular type of list, but they are so important that there is a dedicated configuration.
To access the categories configuration, click on the menu item: System > Categories.
From here, we can define an infinite number of categories, organized into levels.
The database structure of Deepser doesn’t limit the number categories levels and sub-levels, but it is advisable not to use more than 3 levels.
Deepser organizes the categories in a tree structure, easily readable and editable.


To understand better the meaning and the use of the categories, we provide and example.
The Service Type defines the type of the request, so it provides a first macro-categorization.
Think about a Service Operation that is an Incident to report a failure or think about a Service Operation that is a Request to ask for some information.
Talking about the failure reporting, however, we can identify many categories of failures, so that we can assign (eventually using automated systems like Deepser) the processing of the request to the right team that works on a specific topic.
If the failure is on a computer we can create a new category for the Incidents called “Computer failures” and assign it to the IT Support. If the failure is on the air conditioning system of a building we can create a new category called “Air Conditioning System failures” and assign to the Facility Management team.
Categories are used to determine the area of competence of the requests.



Activities are an entity not included in the Service module, but they are managed apart in the Activities module.


Activities are associated to the Service Operations (but can be associated to every other records) and are divided into two main types:

  • Comments are used to communicate and collaborate. They represent the comments of the users regarding a service request and facilitate the collaboration inside the software, avoiding the use of emails and phone calls.
  • Worklog are used to plan and to reporting back the activities to do (or done) to solve a request. They have some fields in common with the comments (eg: a description), but they can also be assigned to a user and store a work time.

Activities (usually only Comments) can be visibile (or not) by the end users in the portal. If visibile, the requester user can verify the comments of the working team, like the request for more information or the communication of a delayed resolution. The user, if qualified, can answer to the comments, making very easy the communicationwith the working team.
Typically, the Worklogs are not visibile to the end user because they are internal data of the organization and are not exposed to customers/users.

Next Users Configuration
Table of Contents