Service Desk

Document TitleService Desk
Document NumberSD-001
Version2.1.3
Author(s)Manager, Product
Approved bySenior Manager, Operations
Last Update DateFebruary 24th, 2026

Introduction

The Service Desk module is used to manage and track support tickets raised within the University. Employees can raise service requests or incident tickets, which are managed, assigned, and resolved by Service Desk Admins and Agents.

The module ensures structured ticket handling, monitoring, transparency, and efficient resolution of service-related issues.

Features:

  • Manage Incidents/Service Requests

  • Service Request for University Services

  • Self Service Portal

Service Ticket Flow:

settings

Ticket Lifecycle Overview

The Ticket Lifecycle defines the sequential stages through which a ticket progresses from initiation to final closure. This structured process ensures proper tracking, accountability, and resolution management.


1. Start

The ticketing process is initiated when an issue, request, or task is identified within the system.


2. Create Ticket

A user or system creates a new ticket to formally record the issue or request.

The ticket captures necessary metadata, including:

  • Summary
  • Description
  • Requestor
  • Priority
  • Category

This information ensures proper classification and routing of the ticket.


3. Submit

The ticket is submitted into the tracking system.

Submission may trigger:

  • System validations
  • Notification workflows
  • Assignment logic (as configured)

Once submitted, the ticket enters the active tracking lifecycle.


4. Open

After submission, the ticket status becomes Open, indicating:

  • The ticket is successfully logged.
  • It is ready for assignment and handling.
  • It is visible in active ticket queues.

5. Assign (Auto / Manual)

The ticket must be assigned to an appropriate agent or team for processing.

Auto Assignment

  • The system automatically assigns the ticket.

  • Assignment is based on predefined rules such as:

    • Skill mapping
    • Workload distribution
    • Service/Sub-Service category
    • Configuration settings

Manual Assignment

  • A Manager or Administrator manually selects the appropriate agent or team.
  • Assignment is based on operational judgment or workload considerations.

6. Processing

The assigned agent or team works on resolving the ticket.

Typical processing activities include:

  • Investigation and diagnosis
  • Communication with the requester
  • Research and troubleshooting
  • Implementing corrective action
  • Delivering the requested service

All actions performed during processing are logged in the system.


7. Closed

When the required work is completed and acceptance criteria are met, the ticket is moved to Closed.

Closure typically includes:

  • Documenting the resolution
  • Updating relevant ticket fields
  • Adding final remarks
  • Notifying the requester

At this stage, the ticket exits the active workflow.


8. Reopen (Optional)

If the requester or system determines that:

  • The issue persists, or
  • Additional work is required

The ticket may be Reopened.

Reopening returns the ticket to an active state for further processing.


9. Closed (Final)

After any required rework and verification:

  • The ticket is closed again.

  • The final Closed status indicates:

    • The issue or request has been fully resolved.
    • No further action is required.
    • The ticket lifecycle is complete.

Dashboard

The Admin has the accessibilities to Total Tickets, Total Open Ticket, Total Closed Ticket, Total Pending Ticket. The dashboard of service desk gives a statistical depiction of given accessibilites, along with the graphical representations of it.

dashboard graphs

Service Desk Module Workflow

settings

Service Desk Workflow Description (As per Flow Diagram)

This section explains the complete workflow of the Service Desk module exactly as represented in the workflow diagram.


1. Start

The process begins when a user initiates the ticketing workflow.


2. User Type Identification

The system determines the type of user initiating the request:

  • Employee → Self Login
  • Admin → On behalf of Employee
  • Agent → On behalf of Employee

If the user is an Employee, they proceed through Self Login.
If the user is an Admin or Agent, they proceed through On Behalf of Employee.

All paths converge at the ticket creation stage.


3. Create Service Ticket

The user clicks on Create Service Ticket to initiate a new request.


4. Fill Ticket Details

The user provides required information, such as:

  • Module
  • Service
  • Sub-Service
  • Details
  • Model Name
  • Serial Number

5. Submit Ticket

Once the required details are entered, the user submits the ticket.


6. Ticket Status = “Open”

After submission:

  • A ticket number is generated.
  • The ticket status becomes Open.
  • The ticket enters the active workflow.

7. Auto Assign Agent Decision

The system checks whether Auto Assign Agent is enabled.

If Auto Assign = Yes

  • The system automatically assigns mapped agents.
  • The assigned agents are linked to the ticket.

If Auto Assign = No

  • The Admin manually assigns the ticket to a specific agent.

Both assignment paths merge into the next stage.


8. Ticket Visible

After assignment (Auto or Manual):

  • The ticket becomes visible to the assigned agent(s).
  • The ticket appears in the agent’s working queue.

9. Agent Reviews Ticket

The assigned agent reviews the ticket and performs necessary actions.

Possible actions include:

  • Add Remarks
  • Send Mail
  • Mark as Pending
  • Proceed toward closure

These actions are part of the Agent Action stage in the workflow.


10. Agent Action Decision

At this stage, the agent determines the next step.

If the issue is resolved:

  • The agent selects Close Ticket.
  • Ticket Status changes to Closed.

11. Ticket Status = “Closed”

Once closed:

  • The ticket exits active processing.
  • The workflow checks if further action is required.

12. Further Action Required?

The system evaluates whether additional action is needed.

If No

  • The workflow ends.
  • Ticket remains permanently closed.

If Yes

  • The ticket is Reopened.
  • Ticket status changes back to Open.
  • The ticket re-enters the active workflow cycle.

13. Reopen Ticket (If Required)

If reopened:

  • The ticket returns to Open status.
  • It flows back into the assignment/processing stage.
  • The lifecycle continues until final resolution.

This workflow ensures structured processing, accountability, controlled assignment, and proper Issue management within the Service Desk module.


Settings

This section contains the configuration detail related to the Service Desk module.

Only the admin(with services_desk_admin role) or module admin (with services_desk_module_admin role) of Service Desk can view and access it.

settings

Service

In this field, we can define and configure the type of services to be used/availed by the university’s employees/agents.

Admin can view the details by clicking on eye icon available in front of every entry.

Admin can add a new type of service by clicking on the Add Services button present on the top right side of the portal and fill in the required details:-

Service Configuration Fields

Field NameDescription
ModuleDropdown field used to select the module under which the service will be created. The selected module determines where the service will be available during ticket creation.
Service NameThe name of the primary service category. This acts as the parent classification under which related Sub-Services can be defined.
DescriptionA brief explanation of the service, defining its purpose and scope. This helps users and administrators understand when the service should be selected.
Status (Active/Inactive)Controls the visibility and usability of the service. When set to Active, the service is available for ticket creation and agent mapping. When set to Inactive, the service is hidden from new ticket creation, though existing tickets remain unaffected.

Note: Once the Add service button is clicked, changes cannot be done.

Impact:

  • Services appear in the ticket creation form.

  • Services act as the parent category for Sub-Services.

  • Service selection determines:

    • Available Sub-Services
    • Agent mapping eligibility
    • Auto-assignment behavior
  • Service status controls visibility across the module.

    • When Service is Active

    • Visible in ticket creation dropdown.

    • Available for agent mapping.

    • Available for sub-service creation.

  • When Service is Inactive

    • Hidden from ticket creation.

    • Existing tickets remain unaffected.

    • Agent mapping cannot be newly created.

Sub-Service

In this field, we can define and configure the type of services to be used/availed by the university’s employees/agents.

Admin can view the details by clicking on eye icon available in front of every entry.

Admin can add a new type of service by clicking on the Add Services button present on the top right side of the portal and fill in the required details:-

Sub-Service Configuration Fields

Field NameDescription
ModuleDropdown field used to select the module under which the Sub-Service will be created. This ensures the Sub-Service is associated with the correct module context.
Sub Service NameThe name of the detailed service category. It represents a specific classification under a parent Service for more granular ticket categorization.
ServiceDropdown field used to select the parent Service to which the Sub-Service will be linked. This establishes the hierarchical relationship between Service and Sub-Service.
DescriptionA brief explanation describing the purpose and scope of the Sub-Service. It helps users select the correct category while creating tickets.
Status (Active/Inactive)Controls the availability of the Sub-Service. When set to Active, it appears in the ticket creation dropdown and is available for agent mapping. When set to Inactive, it is hidden from ticket creation, while existing tickets remain unaffected.

Note: Once the Add Sub-Service button is clicked, changes cannot be done.

Impact:

  • Appears in the Sub-Service dropdown after Service selection and Helps in fine-grained ticket categorization.

  • Used in:

    • Ticket routing

    • Agent mapping

    • Reporting filters

    • Determines assignment scope when auto-assignment is enabled.

  • When Sub-Service is Active

    • Visible during ticket creation.

    • Available in agent-service mapping.

  • When Sub-Service is Inactive

    • Hidden from ticket creation.

    • Existing tickets remain unaffected.

Map Agent-Service

In this field, admin can map and configure the type of services available for particular type or agents.

Admin can view the details by clicking on View icon available in front of every entry.

Admin can map new agent services by clicking on the Add Agent-Service button present on the top right side of the portal and fill in the required details:

Agent-Service Mapping Fields

Field NameDescription
Module NameDropdown field used to select the module for which the agent-service mapping is being configured. This ensures the mapping applies only within the selected module.
RoleDefines the role of the user being mapped. Possible values include service_desk_module_admin or service_desk_agent. The selected role determines the level of access and responsibility within the module.
Agent NameDropdown field used to select the specific agent or module admin to be mapped to a Service and Sub-Service.
Service NameDropdown field used to select the parent Service category for which the agent will be responsible.
Sub Service NameDropdown field used to select the specific Sub-Service under the selected Service. This enables granular assignment control.
Status (Active/Inactive)Controls whether the mapping is valid for ticket assignment. When set to Active, the agent becomes eligible for assignment (including auto-assignment, if enabled). When set to Inactive, the agent is excluded from assignment.
Update OptionThe Admin can edit or update the mapping details by clicking the Update button. As per configuration logic, only permissible fields (such as Status) can be modified after initial creation.

Note: Once the “Map Services” button is clicked, only status can be updated.

Impact:

  • Determines ticket assignment eligibility.

  • Used by Auto Assign Agent To Service setting.

  • Controls:

    • Agent availability in assignment dropdown

    • Automatic assignment logic

    • Restricts assignment scope to mapped agents.

  • Behavior

    • Multiple agents can be mapped to a Service/Sub-Service.

    • Mapping status controls whether the agent is considered for assignment.

  • When Mapping is Active

    • Agent is eligible for ticket assignment.

    • Included in auto-assignment (if enabled).

  • When Mapping is Inactive

    • Agent is excluded from assignment.

Manage Auto Assign Agent To Service

This setting controls whether agents are automatically assigned to a ticket when it is created.

ON: If agents are already mapped to the selected service, all mapped agents will be automatically assigned to the newly created ticket.

OFF: Agents will not be assigned automatically, even if they are mapped to the service. Assignment must be done manually as required.

Manage Module Default Service

This setting controls the visibility of the “Default” service in the service dropdown. When enabled, the Default service is available for selection. When disabled, the Default service is hidden if other services are available for the selected module.

Tickets

Tickets can be created by the following Users:

  • Employees
  • Admin (on the behalf of employee)
  • Agent (on the behalf of employee)
ticket-index

As a employee

Create Service Ticket

Employee can add a new ticket by clicking on the "Create Service Ticket" button present on the top right side of the portal and fill in the required details:-

ticket-form

Ticket Creation Form Fields

Field NameDescription
ModuleSpecifies the module under which the ticket is being raised. This determines the functional area to which the request belongs.
ServiceDropdown field used to select the primary service category related to the issue or request. The available options are based on active Service configurations.
Sub ServiceDropdown field used to select the specific Sub-Service under the chosen Service. This allows detailed classification of the ticket.
DetailsA descriptive field where the user provides complete information about the issue or request. Clear details help in faster diagnosis and resolution.
Model NameUsed to specify the model of the device, system, or asset related to the ticket (if applicable).
Serial No.Used to enter the serial number of the related device or asset for accurate identification and tracking.

a) View

Users can view the details by clicking on the "ticket number" available in front of every entry.

b) Update

Users can update/edit the details by clicking on pencil icon. It consists of details like:

  • Module
  • Service (select from the drop-down)
  • Sub Service (select from the drop-down)
  • Details
  • Model Name
  • Serial No.

c) Submit

Users can finally submit the ticket details after adding/editing by clicking on the Submit button prompting you to be sure.

Note: Once the Submit button is clicked changes cannot be done.

As An Admin

...

Assign to an Agent

Admin can assign to an agent for any action to be performed by clicking on the "Assign to Agent" button present in this function. They can also add comments in the same.

Impact:

  • The ticket is mapped to the selected agent.

  • The ticket becomes visible in the Assigned Ticket section for the agent.

  • The Ticket Acceptance Status tracking becomes active.

  • Email notification may be triggered (if notification is enabled).

a) Close

Admin can close the ticket if no further action is required by clicking on the "Close ticket" button and fill in few details:-

  • Remarks

  • Mail to the user (Yes/No)

b) Spam

Admin can send the ticket to the spam section by clicking on the “Spam” button available to fill in few details:-

  • Decision Status (Spam)
  • Reason

Impact:

  • Ticket status changes to Spam.

  • Ticket moves to the Spam section.

  • Ticket is removed from the active workflow.

c) Send Mail

Admin can send a mail (Internally/External) to the user (Who created the ticket) as and when required by clicking on the “Send Mail” button on the top left side of the portal and fill in the required details:-

  • Email ID
  • Remarks

Note: Once you submit the detail, the mail with the respective content will be forwarded to the respective email id.

All Email id should be separated by comma (,).

d) Re-open

Admin can reopen the closed ticket if further action is required prompting you to be sure.

closed-ticket

Impact:

  • Ticket status changes from Closed → Open.

  • Ticket becomes editable again.

  • Ticket re-enters the active ticket workflow.

  • Previously assigned agent mapping remains unchanged (if applicable).

  • Ticket becomes visible again in active ticket lists.

e) Create Service Ticket

Admin/Agent can add a new ticket by clicking on the “Create Service Ticket” button present on the top right side of the portal and fill in the required details:-

Ticket Creation Form Fields (Admin / Agent)

Field NameDescription
ModuleSpecifies the module under which the ticket is being created. This determines the functional area to which the request belongs.
ServiceDropdown field used to select the primary service category related to the issue or request. Only active Services are available for selection.
Sub ServiceDropdown field used to select the specific Sub-Service under the chosen Service. This enables detailed classification of the ticket.
DetailsA descriptive field where complete information about the issue or request is entered to facilitate accurate processing and resolution.
Model NameUsed to specify the model of the device, system, or asset associated with the ticket (if applicable).
Serial No.Used to enter the serial number of the related device or asset for identification and tracking purposes.
User NameVisible only on Admin/Agent login. Used to select the employee on whose behalf the ticket is being created. This ensures proper ownership and tracking of the request.
Sender EmailVisible only on Admin/Agent login. Used to specify the email address of the ticket requestor for communication and notification purposes.

f) Assigned Ticket

Agents receive the ticket assigned by the admin in this section. Agents can click on the Ticket number to view the ticket details.

g) Send Mail

The agent can send a mail (Internally/External) to the user (Who created the ticket) as and when required by clicking on the Send Mail button on the top left side of the portal and fill in the required details:

  • Email ID

  • Remarks

Note: Once you submit the detail, the mail with the respective content will be forwarded to the respective email id.

All Email id should be separated by comma (,).

h) Close

An agent can close the ticket if no further action is required by clicking on the “Close ticket” button and fill in following details:-

  • Remarks
  • Mail to the user (Yes/No)

i) Re-open

The agent can reopen the closed ticket if further action is required prompting you to be sure.

j) Response to Applicant

In this section, all the responses ever made on this ticket are reflected according to the role/assignment i.e.

  • As an Agent: responses of only assigned/created tickets will be visible.
  • As an Admin: all the responses on the ticket will be visible either created by user/agent/admin or assigned to the agent.

k) Ticket- Acceptance Status

This section helps the admin to view all status of each ticket at a glance at any time.

The status consists of:

  • User ID
  • Ticket Number
  • Any Comment
  • Assign to agent
  • Have agent accepted the ticket?
  • Remarks
  • Assigned at

l) Spam

When any ticket is marked as spam by the admin, it automatically shows status as spam.

Admin can any time shift this ticket back to the ticket section to perform actions like Assign an agent, close, etc by clicking on the “Back to the ticket” button.

m) Logins

There will be 3 types of logins and dashboard:

  • Service Desk Admin

  • Service Desk Module Admin

  • Service Desk Agent

  • Employee/Administrative/Guest

Service Desk Admin

Through this role, admin can configure the setting, create/manage/perform an action on tickets, assign it to agents, and track the responses made on the ticket.

Steps to be followed

1: Login as Service Desk admin to view the ITSD dashboard.

2: Click on the setting section to first configure the Service Desk-related details.

3: To understand the procedure to configure settings go to the Settings section.

4: To understand how to perform action click on the As An Admin.

Service Desk Agent

Create/act on tickets, track the responses made on the ticket.

Steps to be followed

1: Login as an Service Desk agent to act on a ticket.

2: To understand the procedure of how to act a ticket go to the Assigned-Ticket.

Employee

Employees can create a ticket by following below mentioned steps:

1: Login as an Employee to add a ticket.

2: To understand the procedure of how to create a ticket and else can be done by an employee go to the “[As An Employee]

Annexure

Roles

Role NameDescription
service_desk_adminThis role allows the admin to configure Service Desk settings, create and manage tickets, perform actions on tickets, assign tickets to agents, and track all responses across all Service Desk modules.
service_desk_module_adminThis role allows the module admin to configure settings, create and manage tickets, perform actions on tickets, assign tickets to agents, and track responses only for the modules assigned to the user.
service_desk_userThis role allows administrative users to create their own tickets in the Service Desk module, perform permitted actions on those tickets, and view responses and updates related to their submitted tickets.
service_desk_agentcreate/perform the action on tickets,track the responses made on the ticket.

Technical Glossary — Service Desk Module

TermDescription
Service Desk ModuleA system module used to manage service requests, incident tickets, assignment workflows, and resolution tracking.
TicketA system-generated record representing a service request submitted by a user.
Service MasterConfiguration entity that defines primary service categories available during ticket creation.
Sub-Service MasterConfiguration entity that defines detailed service categories linked to a Service.
Master DataConfigurable reference data used across the module for ticket classification and workflow control.
AgentA system user assigned responsibility to process and resolve tickets.
Module AdminA privileged user responsible for module configuration, monitoring, and operational control.
Agent-Service MappingConfiguration that associates agents with specific Service and Sub-Service combinations.
Ticket AssignmentThe workflow action of allocating a ticket to an agent for processing.
Auto AssignmentSystem-controlled process that assigns agents automatically during ticket creation based on configuration.
Ticket WorkflowThe lifecycle process through which a ticket progresses from creation to closure.
Ticket StatusA system-defined indicator representing the current stage of a ticket.
Ticket LifecycleThe complete sequence of ticket states including creation, assignment, processing, and closure.
Activity LogA system-maintained record of all actions performed on a ticket.
RemarksComments or notes added during ticket processing for tracking and communication.
Default ServiceA system-defined service option available during ticket creation when enabled in configuration.
Status FlagA configuration indicator controlling whether a record is active or inactive.
Ticket ClosureThe workflow action that marks a ticket as resolved.
Ticket ReopenThe workflow action that moves a closed ticket back into the active workflow.
Spam ClassificationThe process of marking a ticket as invalid and moving it out of the active workflow.
Email NotificationAutomated or manual communication triggered during ticket lifecycle events.
DashboardA reporting interface displaying ticket counts, status summaries, and activity metrics.
Service QueueLogical grouping of tickets based on Service and Sub-Service selection.
Ticket Acceptance StatusIndicator showing whether an assigned agent has acknowledged the ticket.

Frequently Asked Questions

General FAQs

Q1: What is the Service Desk module used for?
A: The Service Desk module is used to raise, manage, assign, track, and resolve service requests or incident tickets within the university.

Q2: Who can create tickets in the Service Desk module?
A: Tickets can be created by employees, admins (on behalf of employees), and agents (on behalf of employees).

Q3: What is the difference between a Service and a Sub-Service?
A: A Service is the main category of support, while a Sub-Service provides more detailed classification under a Service.

Q4: Can a ticket be edited after submission?
A: No. Once a ticket is submitted, it cannot be edited by the user.

Q5: Where can I see my submitted tickets?
A: Submitted tickets are visible in the user dashboard within the Service Desk module.


Ticket Creation & Workflow

Q6: What information is required to create a ticket?
A: Users must select a Service Queue and provide ticket details.

Q7: Can an admin create a ticket for someone else?
A: Yes, admins and agents can create tickets on behalf of employees.

Q8: What happens after a ticket is created?
A: The ticket enters the active workflow and may be assigned to an agent manually or automatically.

Q9: What does ticket assignment mean?
A: Ticket assignment means allocating the ticket to a specific agent responsible for resolving it.

Q10: Can multiple agents be assigned to a ticket?
A: This depends on the agent-service mapping configuration.


Assignment & Agent FAQs

Q11: How does automatic agent assignment work?
A: When auto-assignment is enabled, mapped agents are automatically assigned to tickets based on the selected Service/Sub-Service.

Q12: What happens if auto-assignment is disabled?
A: Tickets must be assigned manually by the admin.

Q13: Where do agents see assigned tickets?
A: Agents can view assigned tickets in the Assigned Ticket section.

Q14: What is Ticket Acceptance Status?
A: It shows whether the assigned agent has acknowledged the ticket.


Ticket Status FAQs

Q15: What are the possible ticket statuses?
A: Common statuses include Open, Assigned, Pending, Closed, and Spam.

Q16: What happens when a ticket is closed?
A: The ticket is marked as resolved and removed from the active workflow.

Q17: Can a closed ticket be reopened?
A: Yes, admins or agents can reopen a ticket if additional action is needed.

Q18: What happens when a ticket is marked as spam?
A: The ticket is moved to the Spam section and removed from the active workflow.

Q19: Can a spam ticket be restored?
A: Yes, admins can move it back to the ticket section.


Settings & Configuration FAQs

Q20: Who can access Service Desk settings?
A: Only Service Desk Admins and Module Admins can access settings.

Q21: Can a Service be edited after creation?
A: No, once created, the Service configuration cannot be modified.

Q22: Can a Sub-Service be edited after creation?
A: No, only its status can be controlled through configuration logic.

Q23: What happens when a Service is set to inactive?
A: It is hidden from ticket creation, but existing tickets remain unaffected.

Q24: What happens when a Sub-Service is inactive?
A: It cannot be selected during ticket creation.

Q25: What is the Default Service setting?
A: It controls whether the “Default” service appears in the Service dropdown.


Communication & Notifications

Q26: Can admins send emails from the ticket screen?
A: Yes, admins can send internal or external emails directly from the ticket.

Q27: Can agents send emails to users?
A: Yes, agents can send emails to ticket creators when required.

Q28: When are email notifications triggered?
A: Email notifications may be triggered during assignment, closure, or manual mail actions.


Dashboard & Monitoring

Q29: What information is available on the dashboard?
A: The dashboard shows total tickets, open tickets, pending tickets, closed tickets, and graphical summaries.

Q30: Can admins track ticket activity history?
A: Yes, all ticket actions and responses are logged and visible to admins.

Workflow Diagrams

Activity Diagram (AD)

The activity diagram is a flowchart to represent the flow from one activity to another activity. ...

Use Case Diagram (UCD)

A use case diagram is a way to summarize details of a system and the users within the system. ...

📹 Module Training Video ⤤

Edit this page