Service Desk
| Document Title | Service Desk |
|---|---|
| Document Number | SD-001 |
| Version | 2.1.3 |
| Author(s) | Manager, Product |
| Approved by | Senior Manager, Operations |
| Last Update Date | February 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:

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.

Service Desk Module Workflow

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.

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 Name | Description |
|---|---|
| Module | Dropdown 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 Name | The name of the primary service category. This acts as the parent classification under which related Sub-Services can be defined. |
| Description | A 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 Name | Description |
|---|---|
| Module | Dropdown 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 Name | The name of the detailed service category. It represents a specific classification under a parent Service for more granular ticket categorization. |
| Service | Dropdown 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. |
| Description | A 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 Name | Description |
|---|---|
| Module Name | Dropdown 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. |
| Role | Defines 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 Name | Dropdown field used to select the specific agent or module admin to be mapped to a Service and Sub-Service. |
| Service Name | Dropdown field used to select the parent Service category for which the agent will be responsible. |
| Sub Service Name | Dropdown 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 Option | The 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)

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 Creation Form Fields
| Field Name | Description |
|---|---|
| Module | Specifies the module under which the ticket is being raised. This determines the functional area to which the request belongs. |
| Service | Dropdown field used to select the primary service category related to the issue or request. The available options are based on active Service configurations. |
| Sub Service | Dropdown field used to select the specific Sub-Service under the chosen Service. This allows detailed classification of the ticket. |
| Details | A descriptive field where the user provides complete information about the issue or request. Clear details help in faster diagnosis and resolution. |
| Model Name | Used 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.

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 Name | Description |
|---|---|
| Module | Specifies the module under which the ticket is being created. This determines the functional area to which the request belongs. |
| Service | Dropdown field used to select the primary service category related to the issue or request. Only active Services are available for selection. |
| Sub Service | Dropdown field used to select the specific Sub-Service under the chosen Service. This enables detailed classification of the ticket. |
| Details | A descriptive field where complete information about the issue or request is entered to facilitate accurate processing and resolution. |
| Model Name | Used 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 Name | Visible 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 Email | Visible 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 Name | Description |
|---|---|
| service_desk_admin | This 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_admin | This 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_user | This 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_agent | create/perform the action on tickets,track the responses made on the ticket. |
Technical Glossary — Service Desk Module
| Term | Description |
|---|---|
| Service Desk Module | A system module used to manage service requests, incident tickets, assignment workflows, and resolution tracking. |
| Ticket | A system-generated record representing a service request submitted by a user. |
| Service Master | Configuration entity that defines primary service categories available during ticket creation. |
| Sub-Service Master | Configuration entity that defines detailed service categories linked to a Service. |
| Master Data | Configurable reference data used across the module for ticket classification and workflow control. |
| Agent | A system user assigned responsibility to process and resolve tickets. |
| Module Admin | A privileged user responsible for module configuration, monitoring, and operational control. |
| Agent-Service Mapping | Configuration that associates agents with specific Service and Sub-Service combinations. |
| Ticket Assignment | The workflow action of allocating a ticket to an agent for processing. |
| Auto Assignment | System-controlled process that assigns agents automatically during ticket creation based on configuration. |
| Ticket Workflow | The lifecycle process through which a ticket progresses from creation to closure. |
| Ticket Status | A system-defined indicator representing the current stage of a ticket. |
| Ticket Lifecycle | The complete sequence of ticket states including creation, assignment, processing, and closure. |
| Activity Log | A system-maintained record of all actions performed on a ticket. |
| Remarks | Comments or notes added during ticket processing for tracking and communication. |
| Default Service | A system-defined service option available during ticket creation when enabled in configuration. |
| Status Flag | A configuration indicator controlling whether a record is active or inactive. |
| Ticket Closure | The workflow action that marks a ticket as resolved. |
| Ticket Reopen | The workflow action that moves a closed ticket back into the active workflow. |
| Spam Classification | The process of marking a ticket as invalid and moving it out of the active workflow. |
| Email Notification | Automated or manual communication triggered during ticket lifecycle events. |
| Dashboard | A reporting interface displaying ticket counts, status summaries, and activity metrics. |
| Service Queue | Logical grouping of tickets based on Service and Sub-Service selection. |
| Ticket Acceptance Status | Indicator 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.
