Knowledge Base

Self Service

Service Desk

Service Desk - A Deep Dive

Importance of Service Desk

Service requests are utilized to facilitate and standardize the process of seeking specific services, actions, or support within an organization. These requests are essential for streamlining operations, ensuring accountability, and enhancing user satisfaction. Providing a structured framework enables efficient documentation, tracking, and routing of requests to the appropriate teams or individuals. Service requests also allow prioritization, ensuring critical issues receive immediate attention. Service requests can be created by any user as long as they have at least Meta Read permission on the object they want to raise a request for.

Raising Service Requests

Phases in Service Request

Whenever a Service request is raised, each ticket goes through 6 phases:

Precreation Phase
Creation Phase
Summary Phase
Approval Phase
Additional information Phase
Fulfillment Phase

Flow of Service Request:

Please refer to the screenshot below to observe the sequence of phases that a ticket undergoes.

1. Precreation Phase (Select Items)

Upon selecting a service desk template to initiate a request, the user is guided to the Pre-creation phase. Within this phase, objects are selected. It is important to note that, by the Object type stipulated in the service desk template, only objects falling under that particular object type are eligible for selection during the pre-creation phase.

In cases where a request is created at the object level, the pre-creation phase is bypassed, and the process advances directly to the creation phase.

2. Creation Phase (Enter Details & Submit)

During the creation phase, it's necessary to choose or fill in the mandatory fields before moving to the next phase. Optional fields can be filled in, based on the requester's needs. As soon as the request reaches the creation phase, the request will be in a draft state until submitted or discarded. The service request in the draft can be accessed on the My Requests in Service Desk page. If multiple objects are chosen from Data Catalog or Business Glossary or other object types

When raising multiple service requests such as Table metadata change requests, all service requests are displayed on the same page as displayed below:

Users can fill in details for individual requests and view them all together in the review phase as shown below:

The fields that are common across all the templates are:

Field	Description
Requested For User*	The user designates the individual or team for whom the request is made. This is a mandatory field.
Summary*	The user provides a summary of the request, which is a mandatory field.
Description	The user can enter a detailed description of the request, although this field is not mandatory.
Priority*	The user selects the priority level for the request, with options being High, Medium, or Low. This is a mandatory field.
Select (Object) (Primary)*	This field displays the chosen object(s) from the Select items phase.
Permission	Users can request permissions associated with the object type, including options like Data Preview, Data Read, and Data Write.
Expiration date	Users can specify the duration for which this request is valid. They have the flexibility to set an expiration date accordingly.
Business Description	This field is likely to provide information related to the business aspects of the request.
Technical Description	This field is likely to provide information related to the technical details or specifications related to the request.
Associated Tags	Tags can be associated with the request for better organization or categorization.
Associated Terms	Similar to tags, terms may be associated with the request for improved categorization or searchability.

3. Summary Phase (Review Tickets)

Following the completion of the creation phase, the user is directed to the review phase. Here, the service request undergoes scrutiny by the requestor. If multiple requests are generated simultaneously, users can review all the tickets within a single page of the review phase. Typically, the details displayed during the review phase encompass.

Field	Description
Ticket ID	The system generates a unique identifier for each ticket. It serves as a reference number to track and distinguish individual tickets. When the user clicks on the ticket ID, it shows the status of the ticket in the Approval phase. The ticket id can be copied, so that it is easier to search for the ticket on the Service Desk page
Ticket Status	Indicates the current status of the ticket, providing information on whether it is open, in progress, resolved, or has any other designated status.
Ticket Created Date	Represents the date and time when the ticket was initially created and submitted within the application.
Object Type	It specifies the category of object chosen during the item selection process.
Request Type	Describes the nature or category of the request. It helps to classify tickets into different types, such as access requests, metadata change requests, etc.

4. Approval Phase (Approval Requested)

After the review phase, the user proceeds to the Approval phase. Within this phase, the requestor is limited to two actions:

Cloning the request
Withdrawing the request

Withdrawals are only permissible before the fulfillment stage or if the ticket is rejected.
Users who can view the service request have the option to clone the request, leading to the generation of a new ticket that replicates the information entered in the Creation phase. Subsequently, users can modify the details as required and submit a new request. Clone requests can be done even after a request is marked as closed.

Notes:

The option to clone requests remains available even after a request has been officially marked as closed.

Every approver must be a licensed user with author privileges and they should have the capability to clone a request initiated by the requester.

Workflow: Within the approval phase, the designated approvers carry out the task of granting or declining approval for the request. Only Author license users/roles can be approvers for any service request. The sequence of approvers is determined by the predefined order within the workflow.

Additionally, approvers can access pending approval requests from various locations.

Service Desk page
Inbox - Service Desk

The current status and the subsequent action of the ticket are reflected on the top right corner of the request. The current approver can either choose the next action (approve/final approval) or choose “Reject” from the dropdown. If the next action is chosen, the current approver will only see the Status of the ticket in the Approval phase. The next approver will see the status and the next action for the request.
More details about the Actions and corresponding status can be found at Deep Dive - Service Desk Templates and Workflows

Approvers will view the approval phase like below when they have to act on the request.

The current approver acts on the request. After that action, this is how the screen would look for that user. If the action performed was “Verify”, the corresponding status would be “Verified”.

If a single approver rejects a request, the entire ticket is considered rejected. For example, if a request involves three approvers and the second one rejects it, the request is globally declined and advances to the subsequent phase, bypassing the need for the third approver's input.

In the approval phase, all the details about the tickets are displayed such as

Field	Description
Requested by	Displays the user's name who initiated the service request.
Ticket Created Date	Indicates the date and time of the service request initiation.
Requested For user*	Pertains to the individual or team for whom the request is made, applicable specifically to Data Object Access requests. If the user raises an access request for himself/herself, then the requester and the Requested for User name will display the same username. Example: If Alice submits an access request for Maria, the Requester for User field will show Maria's username as "Maria." Likewise, if Alice submits a request for herself, the Requester for the user field will display Alice's username as "Alice."
Object Type	Refers to the category of the object for which the request is raised.
Request Type	Denotes the specific type of service requested, such as Object Access, Data Quality Issue, Term Creation, etc.
Summary*	Displays the summary provided during request creation.
Description	Contains a detailed and relevant description of the request, aiding approvers in understanding its purpose.
Priority*	Specifies the urgency and importance of the service request, categorized into Highest, High, Medium, Low, and Lowest.
Select Object type (Primary)*	It displays the selected object type at the time of ticket creation.
Permission*	Signifies the level of access sought on a specific data object (Data Preview, Data Read, or Data Write) in Object Access requests.
Expiration Date*	Applicable to Object Access requests sets a timeframe for the requested user's access to a specific data object.
Comments	Represent remarks or additional information added to a service request by approvers. Comments are visible in the workflow after approval or rejection decisions. Approvers can include comments with their decisions.

5. Additional Information Phase (Additional Information)

If an approver rejects a ticket, the requester retains the option to reopen the ticket during the Additional Info phase. This can be done either directly or by making modifications to the previously entered information.

6. Fulfillment Phase (Fulfillment)

If all the approvers have given their approval, the request progresses directly from the approval phase to the fulfillment phase. Fulfillment of a ticket happens at different levels, depending on

a. Automatic Fulfillment:
In cases of automatic fulfillment, the status of fulfillment undergoes modifications following the job logs. The approver also has the option to manually adjust the fulfillment status.
i. Template level:

If a request is set for automatic fulfillment at the template level, once all approvals are secured, the fulfillment takes place automatically, and the current status is then indicated in the Fulfillment phase.

ii. Approval level:

For requests with automatic fulfillment at the approval level, the automatic fulfillment process is initiated as soon as the relevant approver grants approval. The status of fulfillment, however, is only visible during the Fulfillment phase. If the fulfillment job is executed successfully, the requested changes outlined in the service request are carried out.

b. Manual fulfillment: For requests with manual fulfillment, the fulfillment status is altered through manual actions carried out by the approver or approvers.
i. Approves Manually:

For requests designated for manual fulfillment, it is the responsibility of the approver or approvers to manually implement the requested changes following the service request.

There are different fulfillment statuses as follows:

Resolved
Fulfillment failed
Fulfillment In Progress
Fulfillment successful
Partially fulfilled.

Notes: The initial status is set as "Resolved."

Upon the successful completion of fulfillment, the requestor has the authority to officially close the ticket. A closed ticket cannot be modified. After the closure, no further alterations can be made to the ticket.

Types of Service Requests

There are two types of service requests:

i. Out-of-the-Box Service Requests

Service Requests created from system-defined templates come with predefined structures that address common user needs and requirements.

ii. Custom Service Requests

In case, where no existing requests meet the end user's requirements, the System Admin has the option to create customized Service Request templates designed for specific purposes. To get further details about these Service Desk templates and Approval Workflows, please refer to the document: Deep Dive - Service Desk Templates and Workflows

Creation of Service Requests from the Service Desk

Primarily Service requests are created from the Service Desk page. All active Service Requests can be raised from here. The different types of System templates that are available to the users are

i. Schema Access Request

Purpose: Meta Read or Meta Write users with no Data Access can raise this request for Schema to access Data. For example, business analysts can raise Data Access requests so that they can get access to the Data and perform their analysis.

Schema Access Request
Phases	Field Values
Select items	Select the Schema(s) for which you need access
Enter Details & Submit	Mandatory fields: Requested for user, Summary, Priority, Permission, Expiration date Non-mandatory fields: Description
Review Tickets	Ticket id, Ticket status, Ticket created date, Object type, Request type
Fulfillment	Automatic fulfillment
Post Approval	The “requested for” user, receives data access for the requested Schema till the expiration date.

ii. Access requests for other object types Request

Table access requests and Report access requests adhere to the same procedure as those for Schema access requests. The sole variation lies in selecting the specific object type instead of Schema during the initial phase and the corresponding object type's presentation in the following stages.

iii. Role Access Request

Purpose: Users can use this request to request any role based on their license type.

Role Access Request
Phases	Field Vales
Select items	Select the Role for which you need access. Only Roles that have the same license type as the user are displayed for selection
Enter Details & Submit	Mandatory fields: Summary, Priority Non-mandatory fields: Description
Review Tickets	Ticket ID, Ticket status, Ticket created date, Object type, Request type
Fulfillment	Automatic fulfillment
Post Approval	The requestor receives access for the requested Role.

iv. Team Access Request

Purpose: Users can use this request to request for any team based on their license type.

Team Access Request
Phases	Field Vales
Select items	Select the Team to which you need access. Only Teams that are created by Users and Roles Admin are displayed for selection
Enter Details & Submit	Mandatory fields: Summary, Priority Non-mandatory fields: Description
Review Tickets	Ticket id, Ticket status, Ticket created date, Object type, Request type
Fulfillment	Automatic fulfillment
Post Approval	The requestor receives access to the requested Team

v. User License Access

Purpose: Viewer license users can use this request to update their license type.

User License Access Request
Phases	Field Vales
Select items	Select the User License for which you need access.
Enter Details & Submit	Mandatory fields: Summary, Priority Non-mandatory fields: Description
Review Tickets	Ticket id, Ticket status, Ticket created date, Object type, Request type
Fulfillment	Automatic fulfillment
Post Approval	The requestor receives access to the requested User License.

vi. Build Lineage Request

Purpose: Users can use this request for building lineage.

Build Lineage Request
Phases	Field Vales
Select items	None
Enter Details & Submit	Mandatory fields: Summary, Priority, Desired Relationship Non-mandatory fields: Description
Review Tickets	Ticket id, Ticket status, Ticket created date, Object type, Request type
Fulfillment	Manual fulfillment
Post Approval	As this is a manual fulfillment, the requester needs to provide specific details for constructing the lineage, and the approver will implement the requested changes after approving the request.

vii. Schema Metadata Change Request

Purpose: Meta-read users can use this template to request changes in metadata for schema objects.

Schema Metadata Change Request
Phases	Field Vales
Select items	Select the Schema(s) for which you want to change metadata
Enter Details & Submit	Mandatory fields: Summary, Priority Non-mandatory fields: Description, Business Description, Technical Description, Associated Tags, Associated Terms, Additional Fields
Review Tickets	Ticket id, Ticket status, Ticket created date, Object type, Request type
Fulfillment	Automatic fulfillment
Post Approval	The changes suggested by the requestor will reflect on the selected Schema after fulfillment is successful.

viii. Metadata Change Request for Other Data Catalog Object Types Request

Purpose: Metadata change requests for other object types such as Table, Table Column, File, File Column, Report, and Report Column adhere to the identical procedure as those for Schema metadata change requests. The sole variation lies in selecting the specific object type instead of Schema during the initial phase and the corresponding object type's presentation in the following stages.

ix. Term Metadata Change Request

Purpose: Meta-read users can use this template to request changes in metadata for Terms.

Term Metadata Change Request
Phases	Field Vales
Select items	Select the Term(s) for which you want to change metadata
Enter Details & Submit	Mandatory fields: Summary, Priority Non-mandatory fields: Description, Business Description, Associated Tags, Detailed Description, Additional Fields
Review Tickets	Ticket id, Ticket status, Ticket created date, Object type, Request type
Fulfillment	Automatic fulfillment
Post Approval	The changes suggested by the requestor will reflect on the selected term after fulfillment is successful.

x. Table Data Quality Issue Request

Purpose: Users can raise issues for Data Quality issues in Tables

Table Data Quality Issue Request
Phases	Field Vales
Select items	Select the Table(s) for which you want to raise the data quality issue
Enter Details & Submit	Mandatory fields: Summary, Priority Non-mandatory fields: Description, Potential Business Impact, Corrective action After a requestor submits a Data Quality issue, in the Data Quality Dashboard the Created Data Quality service requests count is increased.
Review Tickets	Ticket ID, Ticket status, Ticket created date, Object type, Request type
Fulfillment	Manual fulfillment
Post Approval	After the approver approves the request, in the Data Quality Dashboard the Resolved Data Quality service request count is increased. The DQ score of the object is impacted because a service request was raised for a DQ issue.

xi. Data Quality Issues for Other Object Types Request

Purpose: Data Quality issue requests for other object types such as Table Column, File, File Column, Report, Code, Term, and URL adhere to the identical procedure as those for Table data quality issue requests. The sole variation lies in selecting the specific object type instead of Schema during the initial phase and the corresponding object type's presentation in the following stages.

xii. Term Approval Request

Purpose: A term approval request cannot be initiated from the Service Desk because the dropdown menu will be blank during the pre-creation phase. Such a request can only be created from the Business Glossary for the term that is currently in a draft state.

Since this request has automatic fulfillment, after the request is approved by all users the term is published and the Status of the Term is changed from Draft to Published.

Term Approval Request
Phases	Field Vales
Select items	None
Enter Details & Submit	None
Review Tickets	None
Fulfillment	Automatic fulfillment
Post Approval	After approval, the term is published

xiii. Table Creation Request

Purpose: Users can use this request to create a new Table in OvalEdge

Table Creation Request
Phases	Field Vales
Select items	Select the Schema under which the Table would be created
Enter Details & Submit	Mandatory fields: Summary, Priority, Table Name Non-mandatory fields: Description, Business Description, Associated Terms, Associated Tags The Business Description, Associated Terms, and Associated Tags are automatically replicated from the Schema. However, the requester has the option to modify these details before submitting the request.
Review Tickets	Ticket id, Ticket status, Ticket created date, Object type, Request type
Fulfillment	Automatic fulfillment
Post Approval	A new table, when created, is placed under the schema. If the table isn't added to the source system with precise details, it will be purged from the tool's user interface during the next crawl. Despite being removed from the user interface, the table's data is retained in the backend.

xiv. Table Column Creation Request

Purpose: Users can use this request to create a new Table Column in

OvalEdge.

Table Column Creation Request
Phases	Field Vales
Select items	Select the Schema and Table under which the Table will be created
Enter Details & Submit	Mandatory fields: Summary, Priority, Table Column Name Non-mandatory fields: Description, Business Description, Associated Terms, Associated Tags The Business Description, Associated Terms, and Associated Tags are automatically replicated from the Table. However, the requester has the option to modify these details before submitting the request.
Review Tickets	Ticket ID, Ticket status, Ticket created date, Object type, Request type
Fulfillment	Automatic fulfillment
Post Approval	A new table column, when created, is placed under the schema. If the table column isn't added to the source system with precise details, it will be purged from the tool's user interface during the next crawl. Despite being removed from the user interface, the table's metadata that was added when creating the Table is retained in the backend.

xv. Report and Report Column Creation Request

Purpose: New Asset creation requests for other object types such as Report and Report Column adhere to the identical procedure as those for Table and Table column creation requests respectively. The sole variation lies in selecting the specific object type instead of a Table during the initial phase and the corresponding object type's presentation in the following stages.

Report and Report Column Creation Request
Phases	Field Vales
Select items	Select the Report Group under which the Report or Report Column will be created
Enter Details & Submit	Mandatory fields: Summary, Priority, Report Name/ Report Column Name Non-mandatory fields: Description, Business Description, Associated Terms, Associated Tags and Global Custom Fields
Review Tickets	Ticket ID, Ticket status, Ticket created date, Object type, Request type
Fulfillment	Automatic fulfillment
Post Approval	A new report/ report column, when created, is placed under the report group. If the report/ report column isn't added to the source system with precise details, it will be purged from the tool's user interface during the next crawl. Despite being removed from the user interface, the report or report column’s metadata that was added when creating the Table is retained in the backend.

xvi. Project Creation Request

Purpose: Only Project admins can create Projects. Other users can make use of the Project creation request and create Projects for their needs after approval.

Project Creation Request
Phases	Field Vales
Select items	There is no pre-creation phase for this request
Enter Details & Submit	Mandatory fields: Summary, Priority, Project Name, Project Description, and Project Owner Non-mandatory fields: Description The Project Owner dropdown displays a list of Author license users.
Review Tickets	Ticket ID, Ticket status, Ticket created date, Object type, Request type
Fulfillment	Automatic fulfillment
Post Approval	A project is created with the necessary details and is ready to use.

xvii. Tag Creation Request

Purpose: Only System admins can create tags. Other users can make use of the Tag creation request and create Tags for their needs after approval.

Tag Creation Request
Phases	Field Vales
Select items	There is no pre-creation phase for this request
Enter Details & Submit	Mandatory fields: Summary, Priority, and Tag name Non-mandatory fields: Description
Review Tickets	Ticket ID, Ticket status, Ticket created date, Object type, Request type
Fulfillment	Automatic fulfillment
Post Approval	A tag is created with the tag name and is ready to use.

xviii. Term Creation Request

Purpose: Users can use this request to create a new Term in OvalEdge

Term Creation Request
Phases	Field Vales
Select items	Select Domain, Category, and Sub-category. Only Domain is a mandatory field.
Enter Details & Submit	Mandatory fields: Summary, Priority, Term Name, Term Status, Business Description Non-mandatory fields: Description, Associated tags Term status is a dropdown with Draft and Published options
Review Tickets	Ticket id, Ticket status, Ticket created date, Object type, Request type
Fulfillment	Automatic fulfillment
Post Approval	A term is created with the necessary details and is ready to use.

xix. Change Business Glossary Term Structure Request

Purpose: Users can use this request to change the structure of a Term.

Change Business Glossary Term Structure Request
Phases	Field Vales
Select items	Select Domain, Category, Sub-category, and Terms. Only Domain and Terms are mandatory fields.
Enter Details & Submit	Mandatory fields: Summary, Priority, Select Term. Non-mandatory fields: Description, Select Request Domain, Select Request Category, Select Request Sub-category
Review Tickets	Ticket id, Ticket status, Ticket created date, Object type, Request type
Fulfillment	Automatic fulfillment
Post Approval	The term is changed to the requested Domain, Category or Sub-category

Create Service Requests from Object Level

Service Requests can be initiated at the object level from multiple locations.

i. Tags

For tags, the request can only be created from the Tags list view.

ii. Data Catalog

In the case of Data Catalog objects, requests can be launched from the Data Catalog's main view or directly from the object's summary page. The displayed service requests encompass all the service requests specific to that object type, including both system-generated templates and custom-designed templates.

iii. Business Glossary

Just like with Data Catalog objects, service requests for Business Glossary objects can be initiated comparably. These requests can be created from the Business Glossary Terms Summary page. The displayed service requests encompass all the service requests specific to that object type, including both system-generated templates and custom-designed templates.

iv. Projects

For Projects, the request can be created from the Projects page where all the Projects are displayed.

Creating Service Requests from Access Cart

In the System Settings, it's important to confirm that the Access Cart feature is activated. Additionally, within projects, the Access Cart should be designated as the default project. Data Catalog objects like Tables, Table Columns, Files, and File Columns, can be incorporated into the Access Cart. The Access Cart is utilized to generate access requests for the objects that have been included in it.

Objects can be added to the Access Cart from the Data Catalog view or the Object Summary page.

Once added, the objects are segregated based on the object types. Users can select multiple objects or a single object to either Request Access or delete those objects from the Access Cart.

i. Waiting for My Approval

The Service Desk's "Waiting for My Approval" page showcases all service requests associated with a user (Approver).

The page includes various columns, which are:

Field	Description	Sort	Search	Filter
Request Id	The system generates a unique identifier for each ticket. It serves as a reference number to track and distinguish individual tickets.	Yes	Yes	No
Summary	Displays the summary provided during request creation.	Yes	Yes	No
Request Type	Denotes the specific type of service requested, such as Object Access, Data Quality Issue, Term Creation, etc.	No	No	Yes
Object Type	Refers to the category of the object for which the request is raised.	No	No	Yes
Object Name	It displays the selected object name at the time of ticket creation.	No	Yes	No
Status	Indicates the current status of the ticket, providing information on whether it is open, in progress, resolved, or has any other designated status.	No	No	Yes
Requested By	Displays the user's name who initiated the service request.	Yes	Yes	No
Age	Indicates the time since the ticket has been created.	Yes	No	No
Next Action	Users can review the status of the next action to be undertaken for the ticket.	No	No	Yes
Next Approver	In the case of a ticket with an approval flow involving two or more approvers, users can identify the next approver responsible for approving the ticket.	Yes	Yes	No
SLA Status	If the SLA is exceeded then it displays the status of the ticket as “Exceeded”.	No	No	No
Pending Since	Indicates the time since the ticket has been pending for the current approver.	Yes	No	No
Previous Approver	Displays the previous approver's information.	Yes	Yes	No
Created On	Displays the ticket created date and time.	Yes	No	No

Approving/Rejecting Requests
- Users can select a single request or select requests in bulk and select Perform Next Action/Reject from the 9-dots button.
- Users can navigate to a request pending their approval by clicking on the Request ID or the Summary link. This action will take them to the approval stage of the request process, where they have the option to either approve or reject the request.

ii. My Approval History

In My Approval History users can view all the requests that they have approved/rejected. The different columns in the My Approval History page are:

Field	Description	Sort	Search	Filter
Request ID	The system generates a unique identifier to each ticket. It serves as a reference number to track and distinguish individual tickets.	Yes	Yes	No
Summary	Displays the summary provided during request creation.	Yes	Yes	No
Request Type	Denotes the specific type of service requested, such as Object Access, Data Quality Issue, Term Creation, etc.	No	No	Yes
Object Type	Refers to the category of the object for which the request is raised.	No	No	Yes
Object Name	It displays the selected object name at the time of ticket creation.	No	Yes	No
Status	Indicates the current status of the ticket, providing information on whether it is open, in progress, resolved, or has any other designated status.	No	No	Yes
Requested By	Displays the user's name who initiated the service request.	Yes	Yes	No
Age	Indicates the time since the ticket has been created.	Yes	No	No
Next Action	Users can review the status of the next action to be undertaken for the ticket.	No	No	Yes
Next Approver	In the case of a ticket with an approval flow involving two or more approvers, users can identify the next approver responsible for approving the ticket.	Yes	Yes	No
SLA Status	If the SLA is exceeded then it displays the status of the ticket as “Exceeded”.	No	No	No
Pending Since	Indicates the time since the ticket has been pending for the current approver.	Yes	No	No
Previous Approver	Displays the previous approver's information.	Yes	Yes	No
Created On	Displays the ticket created date and time.	Yes	No	No
My Approval Status	It displays the status of the ticket, indicating whether it has been approved or rejected.	No	No	Yes
Approved date	It displays the date and time when the ticket is approved.	Yes	No	No
Rejected Date	It displays the date and time when the ticket is rejected.	Yes	No	No

iii. My Requests

In the My Requests module users can see all the requests that only they have raised. The different columns on the My Requests page are:

Field	Description	Sort	Search	Filter
Request ID	The system generates a unique identifier for each ticket. It serves as a reference number to track and distinguish individual tickets.	Yes	Yes	No
Summary	Displays the summary provided during request creation.	Yes	Yes	No
Request Type	Denotes the specific type of service requested, such as Object Access, Data Quality Issue, Term Creation, etc.	No	No	Yes
Object Type	Refers to the category of the object for which the request is raised.	No	No	Yes
Object Name	It displays the selected object name at the time of ticket creation.	No	Yes	No
Status	Indicates the current status of the ticket, providing information on whether it is open, in progress, resolved, or has any other designated status.	No	No	Yes
Requested By	Displays the user's name who initiated the service request.	Yes	Yes	No
Age	Indicates the time since the ticket has been created.	Yes	No	No
Next Action	Users can review the status of the next action to be undertaken for the ticket.	No	No	Yes
Next Approver	In the case of a ticket with an approval flow involving two or more approvers, users can identify the next approver responsible for approving the ticket.	Yes	Yes	No
SLA Status	If the SLA is exceeded then it displays the status of the ticket as “Exceeded”.	No	No	No
Pending Since	Indicates the time since the ticket has been pending for the current approver.	Yes	No	No
Previous Approver	Displays the previous approver's information.	Yes	Yes	No
Created On	Displays the ticket created date and time.	Yes	No	No

Notes: Tickets that are in Draft state can either be discarded or Submitted from this page.

iv. All Requests

On the All Requests page, users can see every request that has been made within the tool by all users. However, this page is exclusively accessible to users who hold an Author license. The different columns in the All Requests page are:

Field	Description	Sort	Search	Filter
Request ID	The system generates a unique identifier for each ticket. It serves as a reference number to track and distinguish individual tickets.	Yes	Yes	No
Summary	Displays the summary provided during request creation.	Yes	Yes	No
Request Type	Denotes the specific type of service requested, such as Object Access, Data Quality Issue, Term Creation, etc.	No	No	Yes
Object Type	Refers to the category of the object for which the request is raised.	No	No	Yes
Object Name	It displays the selected object name at the time of ticket creation.	No	Yes	No
Status	Indicates the current status of the ticket, providing information on whether it is open, in progress, resolved, or has any other designated status.	No	No	Yes
Requested By	Displays the user's name who initiated the service request.	Yes	Yes	No
Age	Indicates the time since the ticket has been created.	Yes	No	No
Next Action	Users can review the status of the next action to be undertaken for the ticket.	No	No	Yes
Next Approver	In the case of a ticket with an approval flow involving two or more approvers, users can identify the next approver responsible for approving the ticket.	Yes	Yes	No
SLA Status	If the SLA is exceeded then it displays the status of the ticket as “Exceeded”.	No	No	No
Pending Since	Indicates the time since the ticket has been pending for the current approver.	Yes	No	No
Previous Approver	Displays the previous approver's information.	Yes	Yes	No
Created On	Displays the ticket created date and time.	Yes	No	No

Notes: Users can select multiple tickets that are pending their approval and perform bulk actions to approve or reject them. Additionally, they can manage their requests that are in the draft state by choosing to either submit them for processing or discard them if they are no longer needed.

Service Request - Notifications

Any notifications related to the Service Desk can be viewed in the Inbox, which can be accessed under the User’s icon at the top right corner of the tool.

Upon the creation of a service request and its entry into the review phase, notifications are dispatched to the "requested for" user following the configurations outlined in My Profile.
As the service request advances into the approval phase, the initial approver is promptly notified that the ticket is pending approval.
Subsequently, upon the initial approver's approval, the subsequent approver in the sequence is notified.
Upon receiving approval from the final approver, notifications are issued to both the "requested by" and "requested for" users, conveying that their request has been approved.
Conversely, if any approver rejects the request, notifications are sent to both the "requested by" and "requested for" users, notifying them of the request's rejection.
In cases where the SLA is violated by an approver, notifications are dispatched to the respective approver, indicating that the SLA has been breached and prompting them to expedite the approval process. These SLA notifications are consolidated and dispatched once daily. The frequency of these SLA notifications is set to be sent once a day.
The corresponding approver receives pre-violation notifications for service level agreements (SLAs) if a request is projected to breach the SLA on a subsequent day. Like post-violation notifications, these pre-violation alerts are also dispatched once daily. But for a particular request, the pre-violation alert would be delivered only once, which is before the day of the actual SLA time.

System Settings

The maximum number of approvers that a workflow can have is configured in the system settings. The default value is 10 and the maximum that can be enabled is 20.
The maximum number of users in a team/role that can approve a request is configured in system settings. The default value is 5 and the maximum number of users to approve from a team/role for a request can be set at 20.
The cap on the number of requests that can be bulk approved or rejected is determined within the System Settings. The preset and maximum threshold is established at 50, but users have the option to tailor this limit to better suit their organization's needs.

Advanced Jobs

Name of Advanced Job: Service Desk V1

This advanced job helps to migrate existing service desk templates to a new version. This allows users to select existing templates and fill out the mandatory fields before raising service requests on multiple objects on behalf of multiple users.

Notes: No attribute is required to execute this job. This job can be run once when OvalEdge is used for the first time and each time when the version of the tool is updated. It can only be executed by the System Admin.