Tickets
A Ticket can be defined as an unplanned interruption to an IT service, reduction in the quality of an IT service, or failure of an asset/Item that has not yet impacted service. Ticket Management is the process responsible for managing the life cycle of tickets. The goal of ticket Management is to restore standard service as quickly as possible with minimal to no disruption to the business. This ensures that the highest achievable levels of availability and service are maintained.
How does it work?
Tickets can be created by end-users/requesters through the web portal or mobile app access, via email, or by a technician on call. When tickets are created from email, the message's subject line becomes the ticket summary, the message body becomes the description, and the source field is set to Email.
The quick action panel helps technicians resolve tickets quickly, reducing ticket resolution time by 80%.
Location Mapping
Location Mapping automatically routes incident tickets to specific teams based on the requester’s location. This eliminates the need for manual team assignment and ensures quicker response from the appropriate support group.
During ticket creation, the system identifies the default or selected location of the requester.
This location matches the location configuration of the teams set in the Teams module.
If a match is found, the ticket is automatically assigned to the respective team.
If no match is found, the ticket remains unassigned or follows the default assignment logic.
Example Use Case
A Delhi – HQ – 4th Floor user logs a ticket for internet issues.
The system detects the requester’s location and matches it with the "IT Support – North" team configured with that location.
The ticket is routed instantly to the right team without manual selection.
What you see on the screen
The tickets page lists all tickets, including details such as summary card, impact service, status, subject, team, requester name, and actions, sorted by time. Refer to the 'Working on a Ticket' section for detailed information.
Bulk Action
When selecting multiple tickets at once, various actions can be performed:
Bulk Actions | Basic Details
Tag
Add or remove tags for selected tickets to categorize and organize them efficiently.
Merge
Combine multiple selected tickets into a single ticket to avoid duplication and streamline tracking.
Assignment
Assign the selected tickets to a specific team or individual for resolution.
Delegate Approval
Forward approval responsibility for the selected tickets to another approver or team.
Assign Peer Review
Assign peer review for the selected tickets in bulk, enabling reviewers to provide structured feedback.
Submit Peer Review
Submit review feedback for selected tickets based on the assigned peer review template.
Show Peer Reviews
View existing peer reviews associated with the selected tickets.
Delete
Permanently remove selected tickets from the system.
Retry Failed API
Re-trigger API calls for tickets where previous integrations or updates failed.
Resolve
Mark selected tickets as resolved directly from the bulk action menu.
Bulk Update
Update multiple incidents at once by modifying fields such as priority, urgency, severity, status, impact service, or assignment. The system ensures validation, requires a reason for updates, and notifies the user of any failed or partially successful updates with clear error messages. Successful updates are logged in both the audit history and the recent activity, while cancelled operations do not make any changes.
Working on a ticket
The service desk is the core of Ticket Management. Though there are multiple ways to record a ticket, Ticket work or resolution is in the hands of Technicians.
Before working on the Ticket, it is necessary to understand its life cycle and the key components within Infraon's Ticket module.
Components
Ticket Summary Card - The ticket summary card briefly summarizes the ticket. This summary contains all the important information needed to work on the ticket. Details include:
Ticket ID – Auto-generated when a ticket is created. Click on the ticket ID to view the communication history, reply to and forward emails, add notes, analyze, add symptoms and root causes, and view and add work logs. You can resolve a ticket from this screen too.
Ticket Source – This shows how the ticket was submitted.
Priority – The priority of the ticket (derived from the asset)
Asset ID - Asset for which the ticket is raised. Click on the asset ID to view detailed asset information.
Analyze – Used to view details of the ticket
Requester Icon – Displays the name of the requester (initial)
Subject – Subject of the ticket (derived from the ticket subject line)
Comment – The requester or technician’s comment on the ticket
All the users associated with the ticket will be informed whenever updates are made. This includes the requester, followers, and assigned team members, who will receive an email notification whenever a new comment or note is added to the ticket.
Suppose a technician adds a Root Cause note for a ticket related to a network outage. In that case, the system will immediately send an email notification to the requester, all followers, and the IT support team. The email will clearly mention the type of note, who added it, and the content provided.
Communication
The Communication tab acts as your central hub for all ticket interactions. Clicking on it opens a dedicated window displaying the complete communication history, including emails, SMS messages, and any comments added throughout the ticket lifecycle.
This streamlines resolution by allowing technicians to access all relevant information quickly, keeping everyone informed—assignee, team, and requester.
The tab also empowers technicians to send emails and SMS messages directly to the end-user without leaving the window.
For added convenience, Infraon Infinity features a dynamic section with a requester dropdown, eliminating the need for manual entry. Furthermore, technicians and end-users can attach files and add signatures for enhanced clarity and authenticity.
The summary card details can be configured to suit requirements. Click on the configure icon to customize the summary card.
Working on a ticket
The service desk is the core of Ticket Management. Though there are multiple ways to record a ticket, Ticket work or resolution is in the hands of Technicians.
Before working on the Ticket, it is necessary to understand its life cycle and the key components within Infraon's Ticket module.
The Right Panel
Impact Service: To select the service that has been impacted
Status: Displays the current status of the Ticket. Technicians can change the status from here too
Subject: Subject of the Ticket
Team: The team assigned to work on the Ticket
Requester Name: Name of the requester
Actions: Quick action icon to work on the Ticket
The Ticket summary card and the quick action floater help to cut the technician’s resolution time by 80%.
Ticket Quick Actions
Resolve: Click to close the ticket. The resolution date and time are recorded automatically. The technician must change the status, add a resolution comment, and enter a resolution comment to finish the process.
When a technician selects the Resolve option, the Resolve Ticket dialog box opens.
The following fields are displayed:
Status
Select from the drop-down
Update the ticket status to 'Resolved' or 'Waiting for Closure'.
Resolution Date*
Auto-populated, read-only
Captures the date and time when the ticket is resolved. Default: system date & time. This field cannot be edited.
Resolution*
Click to input text
Provide detailed resolution steps or root cause. Example: Rebooted the server to restore services or applied for the latest security patch.
Resolution Comment (New)
Click to input text
Add additional notes, clarifications, or supporting details for the resolution. Example: The user confirmed resolution via email, or a Workaround Is documented until a permanent fix is available.
Resolve
Click to action
Confirms resolution and updates the ticket with the entered details.
Closure Action
When closing the ticket, the Close Ticket dialog box opens.
Actual Closure Date*
Auto-populated, read-only
Captures the date and time when the ticket is officially closed. Default: system date & time. Note: This field cannot be edited.
Miscellaneous
Ticket aging for helpdesk/ ITSM close and resolve conditions: Grid View includes Aging Metric. Track ticket resolution time accurately. Click 'Resolve' or 'Close' to stop the aging clock. Get detailed aging reports based on resolved status.
Assign To: Click to assign the Ticket. Tickets can be assigned to a user individually or a user from a specific team, expertise, or level.
Quick Edit: To perform quick edit actions like status, priority, urgency, severity, impact, impact service, and the Ticket assignee. Use the ‘Detailed Edit’ button to edit the Ticket details.
Edit: To edit the Ticket in detail.
Delete: To delete the Ticket. This action cannot be reverted.
Additional Actions: Use the additional action button to view the ticket history and convert the Ticket to a Knowledge Base. The ‘Edit Options’ icons customize the additional action options. You can select up to four actions.
Ticket Grid Page Actions
Apart from these, the Ticket page has:
Expand the icon to view Ticket filters.
Search bar to help search for a specific Ticket using the Ticket number, assignee, etc.
Calendar to filter the Tickets by a specific day, date, or date range.
Convert Ticket to Request—If the technician feels that the ticket is more of a Request, the ticket can be converted into a Request.
Convert Ticket to KB—This option converts the ticket into a Knowledge Base (KB). This action is possible only if the ticket's status is "Resolved" or "Closed."
Add Change—A change may implement a ticket resolution. A Change Request can be added to this ticket. This action is possible only if the ticket's status is 'Open', 'In Progress', or 'On Hold'.
View Change - This option is visible if a change request has been created for a ticket. This can be clicked to view the related change request.
Tag - Select A ticket to view the tag option. Tagging is a way to group Tickets.
Merge - Select more than two Tickets to view the merge option.
Pause the icon to pause the auto-reload.
Configure the icon to configure the summary card and column selection.
Icons to toggle between list and smart grid view.
Ticket Panel view actions
Enhance ticket management with the ability to modify ticket details, track SLA status, and effortlessly streamline communication. With the integrated panel view, experience efficient incident, request, and problem handling.
The ticket panel view has been revamped. The improved interface offers enhanced data visibility, with aging metrics conveniently displayed.
Clone
Create a duplicate of the selected ticket. You can configure it by updating:
General details (Requester, Asset)
Information details (Impact Service, Service Classification, Status)
Assignment details (Team and Assignee).
Delete
Permanently remove the ticket from the inventory.
Attachment
Redirects to the Attachments tab, where you can add or view relevant documents linked to the ticket.
Communication
Redirects to the Communication tab, where you can record or review related communication details.
Recent Activities
Redirects to the Recent Activities tab, displaying a timeline of ticket actions and updates.
Interaction
Redirects to the Interaction tab, where you can log or access interactions related to the ticket.
SLA
Redirects to the SLA tab, showing SLA metrics, breach status, and compliance tracking.
Relation
Redirects to the Relations tab, where you can link the ticket to related incidents, problems, changes, or requests for better context.
Resolve
Mark the ticket as resolved, changing its status. Resolution details, such as closure remarks or resolution notes, can be updated during this action.
Assign Peer Review
Assign a ticket for peer review, enabling selected users or teams to provide structured feedback.
Select Team → Choose the team responsible for the review.
Assign To → Pick a specific reviewer within the team.
Due (in Days) → Define the deadline for completing the review.
Click here for a step-by-step guide to creating a template.
Submit Peer Review
In the Smart Grid view, hover over the required ticket and click the Submit Peer Review action icon.
The review form opens based on the template configured. Fill in the details and submit your feedback.
Relation
Ticket relationships follow the same structure as defined in Problem Management. For a detailed explanation of how linked records work, refer to the Problem Management page.
Auto-Conversion of Recurring Incidents to Problems
Incidents that occur repeatedly with the same or similar symptoms can be automatically converted into a Problem. This helps ensure that recurring issues are escalated for root cause analysis and long-term resolution.
How It Works
The system monitors incidents logged with the same requester, service, or asset.
When five or more incidents occur within 14 days, the most recent incident is converted into a Problem.
A relationship is created between all related incidents and the Problem record.
If the threshold is not reached, or the incidents occur outside of the 14-day window, no conversion takes place.
All conversions are logged in the audit trail, and the Relations tab displays the linked incidents.
Conversion Rules
5 or more incidents from the same requester + same service within 14 days
The latest incident is converted into a Problem. A relation was established with all five incidents.
Requester logs 5 VPN connectivity issues in 2 weeks → 5th incident becomes a Problem.
Less than five incidents from the same requester + same service within 14 days
No conversion occurs.
Requester logs 3 Email login issues in 14 days → remain as incidents only.
5 or more incidents linked to the same asset within 14 days
The latest incident is converted into a Problem. A relation was established with all five incidents.
Multiple users log printer malfunction incidents for the same printer asset → 5th incident becomes a Problem.
Less than five incidents linked to the same asset within 14 days
No conversion occurs.
Only two incidents logged for Laptop ID-1234 in 14 days → no Problem created.
5 or more incidents occur but span beyond 14 days
No conversion occurs.
5 VPN issues logged over 2 months → no automatic conversion.
Audit and Logs
Conversion details are recorded in the audit trail, including:
Incident IDs involved
Problem ID created
Date and time of conversion
Matching criteria (Requester + Service / Asset)
The Relations tab of the Problem shows all linked incidents for full traceability.
More Options
Users can access additional actions from the three-dot menu available on each ticket. These actions allow technicians to link, convert, or extend tickets into other ITSM processes.
Available Options | More Options
Add Request
Creates a new Service Request using the details of the existing ticket. The original ticket remains open.
Use when the ticket highlights the need for an additional service. Example: User reports laptop issue → create a request for a replacement device.
Convert to Request
Convert the ticket into a Service Request.
The ticket is closed automatically.
A new Request ID is generated.
All communications, attachments, and activities are moved to the request.
The requester receives an email with both the Ticket ID and the Request ID.
Use when an incident was logged incorrectly and should instead be handled as a service request. Example: A password reset is logged as an incident, but it correctly belongs under service requests.
Add Change
Creates a new Change record linked to the ticket.
Use when the resolution of an incident requires a configuration change. Example: Applying a patch to fix a recurring system bug.
Add Problem
Creates a new Problem record linked to the ticket.
Use when multiple incidents suggest a common root cause. Example: Several users report slow email access → add a Problem for mail server investigation.
Convert to Request
When using Convert to Request, the following system actions occur:
Ticket Closure:
The original incident ticket is automatically closed.
New Request Creation:
A corresponding service request is created with a new Request ID.
Communication and Attachments:
All ticket communications, attachments, and recent activity logs are moved to the request.
Requester Notification
The requester receives an email notification containing:
Original Ticket ID
New Request ID
Conversion details
History Retention (Scenario 2):
The closed ticket’s history remains visible for audit purposes.
The new request shows the conversion event in its recent activity log.
Convert to Request | Basic Details
Reported by
System-generated field
Automatically shows who reported the original ticket. Example: John Doe (Requester).
Select Team
Choose from available groups
Select the support team responsible for handling the request. Example: IT Helpdesk Team.
Assignee
Choose an assignee from the team
Assigns the request to a specific technician. Example: Alex Brown (Technician).
Subject
Editable text field
Title of the request. Should be clear and concise. Example: VPN Access Request for Remote Employee.
Request For
Select from the drop-down (Impact Service)
Choose the service impacted or requested. Example: Email Services / VPN Access.
Request Type
Select from the drop-down
Defines the type of request. Options:
Provisioning Request
Purchase
Request for Information
Security
Onboarding
Offboarding
Service Classification
Select an option from the drop-down
Categorize the request according to the ITSM service classification. Example: End-User Computing.
Priority
Predefined by system (editable if needed)
Indicates the urgency of the request. Options include: Critical, High, Medium, Low.
Followers
Select users to follow the request
Followers receive updates about request progress. Example: Add Project Manager as a follower.
Internal Note
Free text field
Used by technicians to request details or context. Not visible to the requester. Example: Request for provisioning a new laptop with the required software for onboarding.
Attachments
Upload files
Add any relevant documents/screenshots. Example: Employee joining form.pdf.
Submit as New
Action button
Finalizes the conversion and creates a new request with the provided details.
Click Submit to complete the conversion and generate a new request with the entered details.
Delegate Approval
Delegation allows users to assign their approval duties to another person for a specified time. It ensures that approvals continue smoothly when the primary approver is unavailable due to planned leave, travel, or other reasons.
How It Works
Users can configure delegation rules directly from their profile settings.
Delegation can be applied in two ways:
Manual Delegation – Select an individual approval service and reassign them to another approver.
Bulk Delegation – Apply delegation to multiple approval services simultaneously, across modules.
When delegation is active, the delegated approver receives the pending approval requests and can take action on behalf of the original approver.
A defined start and end date can be set for the delegation period, after which the responsibilities revert automatically to the original approver.
All delegation actions are tracked in the audit logs, ensuring complete transparency and compliance.
Delegation Privileges
Delegation can only be performed by privileged members. Infraon provides delegation to:
Change/Release/Request Manager – They can delegate approvals when items are in the “Waiting for Approval” state.
Owners of the Assigned Team – They are allowed to delegate the approval.
Team Members (not part of the approval sequence) – They may also be chosen as delegates.
Configured Assignees – If no manager is assigned (e.g., in a Request without a Request Manager), the configured assignee can perform the delegation.
Business Rules/ Automation – Delegation can also happen automatically through configured rules (e.g., duration-based delegation, fallback users, or bulk delegation).
Add Delegation
You can add delegation rules using three methods:
Manual – Assign delegation for a single approval.
Bulk – Reassign multiple approvals at once.
Business Rule – Automate delegation based on predefined conditions.
Delegate Manually
Go to the required service (Ticket, Request, Release, or Change).
Hover over the service and select Approval Status.
In the pop-up window, you will see the list of required approvals. Click Change to delegate.
From the drop-down list, choose the approver to delegate. (This list is populated and configured from the Teams module.)
Click Submit to confirm the delegation.
Bulk Delegation
Navigate to the required Service and select the checkboxes of the items you want to delegate.
Use the drop-downs to assign delegation:
Label
Action
Description/Example
Delegate From
Select the current approver
The user currently assigned for approval. Example: John – Change Manager.
Delegate To
Select the new approver
The user who will take over the approval. Example: Sarah – Backup Approver / Team Lead
Click Submit to confirm the delegation.
Business Rule for Delegation
There are two Business Rules that can be created for the Delegation process:
Delayed Approval Delegation
Immediate Approval Delegation
Delayed Approval Delegation
This rule automates the delegation of approvals when the original approver does not act within a specified time.
This rule allows the system to monitor pending approvals, send a reminder before the delegation time, and then automatically reassign the task to a fallback approver once the set duration has passed.
Click here to learn more about configuring Business Rules.
Use Case
Creed and Erin Hannon are designated approvers for a change request.
If they fail to provide approval within the defined timeframe (for example, 1 day, 1 hour, and 5 mins), the system automatically delegates the task to Yogi S, who acts as the fallback approver.
A reminder notification is sent before delegation (for example, 2 hours before the deadline) so the original approvers still have an opportunity to act.
In this scenario, if Creed and Erin do not approve within 1 day, 1 hour, and 5 minutes, the system automatically delegates the approval to Yogi. A reminder notification is also triggered 24 hours before the delegation taking place.
Immediate Approval Delegation
This rule automates the delegation of approvals instantly, without requiring a defined time frame. As soon as the approval task enters the Waiting for Approval stage, it is reassigned to the configured fallback approver.
Use Case
The module, type, and precedence are to be defined while creating the rule.
In the rule setup, Creed and Wallace are selected as the original approvers.
Their approval tasks are immediately delegated to Erin Hannon, who acts as the fallback approver.
No duration or reminder configuration is required, as the delegation happens instantly.
In this scenario, as soon as a request, ticket, change, or release requires approval, the task is automatically delegated from Creed and Wallace to Erin Hannon without waiting.
Last updated
Was this helpful?