Service Desk System Defined Templates

Article Summary

This article provides an overview of system-defined templates, highlighting their key differences from custom templates. It explores the service desk template interface and discusses who can access and work on system-defined templates. A chart is included to illustrate the various types of system-defined service request templates. Additionally, the article touches upon integration with external platforms and offers insights into configuring an approval workflow.

Introduction

Templates can be categorized into two types: system-defined Service Desk Templates and Custom-defined Templates. System-defined Service Desk Templates refer to pre-configured templates provided by OvalEdge software as part of their default offering. These templates come with predefined workflows and settings to address common service request scenarios. They serve as a starting point for users to quickly create service requests without extensive customization.

On the other hand, Custom Service Desk Templates allow users to create and configure templates according to their specific requirements and preferences. Users have the flexibility to define their own workflows, approval processes, and fields based on their unique needs. Custom templates enable users to tailor the service request management system to align precisely with their organization's specific workflows, policies, and business processes.

The primary difference between system-defined and custom Service Desk Templates lies in the level of flexibility and control granted to users. System-defined templates offer a predefined structure and workflow, which can be advantageous for organizations that follow standard service request processes. Conversely, custom templates provide users with the freedom to design templates that precisely align with their organization's requirements, allowing for greater customization and adaptability.

Exploring the Service Desk Template Interface

Take a deep dive into the Service Desk Template Interface, a robust tool that enables users to efficiently manage and integrate service request templates with renowned platforms like Jira, ServiceNow, and Azure DevOps. This interface provides a streamlined view for effortless addition, deletion, and customization of templates while delivering vital details including template ID, name, and request type. With its user-friendly design and convenient features, the interface guarantees a meticulously organized and consistently updated template library.

Column Header	Description
	Seamlessly integrates service request templates with Jira or ServiceNow for streamlined request management and collaboration.
+	Easily create custom templates to fit your organization's specific needs and capture essential information for efficient request handling.
Nine Dots	Use the nine-dots menu to delete custom templates you no longer need, ensuring a well-organized and up-to-date template library.
ID	Each Service Request Template is assigned a unique identifier. You can use this ID to reference or identify specific templates.
Name	The name of the template helps you easily recognize and categorize different templates based on their purpose or function.
Description	The Description provides a brief explanation and scope of the template.
Request Type	The Request Type field specifies the nature of the request, such as Access, Content Change, Report Data Quality issue, or others. It allows for easy categorization and filtering of templates.
Object Name	The Object Name field indicates the type of object or entity for which the template is created. It helps you identify the specific context or area of the application.
Connector Type	The Connector Type field specifies the type of connection used, such as API integration, database connection, or other connectivity methods.
Connector Name	The Connector Name field displays the name of the connection associated with the template. It helps you identify the specific connector used for data exchange or integration.
Domain	The Domain field indicates whether the template is linked to a global domain or a particular domain. This information helps determine the template's reach and accessibility across different domains.
Template Type	The Template Type field specifies whether the Service Request Template is a system-defined template or a custom template created by users.
Approval Workflow Type	The Approval Workflow Type field displays the type of approval workflow associated with the template. It helps you understand the process through which requests are reviewed and approved.
Mapper	When template-level integration fields are populated, an automatic popup enables the administrator to select the desired mapping fields for accurate reflection in the external ticketing platform.
Status	The Status field indicates whether the template is Published or in Draft mode. System-defined templates are published by default and cannot be changed to draft status.
Activation	The Activation field shows whether approval for the template is currently Active or Inactive. You can set a template to inactive mode when it is no longer necessary and needs to be hidden from the list.
Created By	The Created By field displays the name of the user who initially created the template. It helps identify the author of the template.
Created On	The Created On field indicates the date and time when the template was initially created.
Updated By	The Updated By field displays the name of the user who made the most recent changes to the template.
Updated On	The Updated On field indicates the date and time when the last changes were made to the template.

System-defined Service Desk Templates can typically be accessed and worked on by administrators or individuals with the appropriate privileges and permissions within the OvalEdge Application. These templates are often part of the default offering provided by OvalEdge and are designed to cater to common service request scenarios. Administrators or designated users with administrative rights can configure, modify, and manage these system-defined templates to align with the requestor's requirements and processes.

Understanding the Different Types of System-defined Service Request Templates

Request Type	Data Objects	Description	Default Approver	Fulfillment Mode
Access	Schema/Tables/Reports/Global Domain	Request access permissions for data objects	Owner	Automated
Content Change	Table/Table Column/File/Report/Business Glossary objects	Request edit permissions on the metadata of data objects	Steward	Automated
Data Quality	Table/Table Column/File/File Column/Report/Business Glossary/URL/Query	Notify the approver to verify the data quality of a data object	Steward	Manual
Crawl/Profile	New or existing database/new schema in an existing database	Request an approver to crawl or profile a database	Steward	Manual
New Asset Request	Table/Table Column/Report/Business Glossary	Request the approver to create a new data object at the data source	Owner	Automated
Build a Lineage	Lineage between different data objects	Request approvers to build a lineage between objects	Steward	Manual
External Access	Asset	Request access permissions to external (on-cloud) applications	Owner	Automated
Others	Tables/Table Columns/Files/Report/Business Glossary/Project	Notify approvers of additional changes required to data objects	Steward	Manual
Access	RDAM Oracle Access (Tables)	Request access to RDAM Oracle Access (Tables)	Owner	Automated
Access	Snowflake Access (Tables)	Request access to Snowflake Access (Tables).	Owner	Automated
Access	S3 Access (File/Folder)	Request access to S3 (Files/File Folders)	Owner	Automated
Business Term Approval	Business Glossary	Request for Term Approval	Steward	Automated
API External Access	Asset	API External Access Request	Owner	Automated

Integration with an External Ticketing Platform

Integration at OvalEdge enables seamless communication with external ticketing platforms like Jira, ServiceNow, and Azure DevOps. This integration eliminates software switching and ensures consistent updates between OvalEdge's service desk and external platforms. Tickets created or updated in OvalEdge sync with the external platform, maintaining data consistency. Admins can initiate integration through the template page, map fields between templates, and save configurations for future use.

Fulfillment Modes

Fulfillment refers to the process of managing service requests raised by users and ensuring their timely and efficient completion. In OvalEdge's Service Desk, there are two primary fulfillment modes: manual and automated.

Manual fulfillment mode involves a detailed process that requires human intervention to fulfill the request. It includes tasks such as assigning the request to the appropriate team or individual, tracking its progress, and manually executing necessary actions. This mode allows for greater flexibility and customization in handling complex or specialized requests that require human expertise.

In contrast, the automated fulfillment mode leverages advanced job and system-defined classes to streamline and automate the fulfillment process. This mode is designed to handle repetitive, routine, or standard requests that can be fulfilled automatically without human intervention. By utilizing predefined workflows, triggers, and actions, the automated flow minimizes manual effort, speeds up request resolution, and ensures consistent and efficient fulfillment.

Configuring and Associating an Approval Workflow

By using an approval workflow, OvalEdge streamlines the approval and rejection of service requests. Admin users can configure the workflow based on their organization's needs, specifying the request type and choosing the desired approvers. Multiple users or teams can be added as approvers, and different approval options are available. Once approved, the request moves to the next approver until final approval is given. If any approver rejects the request, the process stops, and the request is marked as "Rejected”. Subsequently, the rejected request is returned to the original requestor. The configuration settings and customization options allow for flexibility in managing the approval workflow.

How can a system template be made inactive?

To make a system template inactive, open the desired service desk template. Then, click on the nine dots located at the top right corner of the screen and select the option "Inactive." Once the template is marked as inactive, it will no longer be visible or available on the service desk page or the object page.

How to Clone a system template?

By default, the fields in system templates cannot be edited directly. However, if a user wishes to make changes to the fields in a system template, they can follow a process called cloning. Here are the steps to clone a template:

Click on the "Clone Template" option.
Enter a name for the cloned template.
Add new fields or modify existing fields in the cloned template as desired.
Associate an approval flow with the cloned template if needed.
Publish the cloned template to make it available for use.
Set the existing template to an inactive status.
Activate the cloned template for use.
The cloned template will now be accessible on the object page (represented by nine dots) and within the service desk.

All the template details, including their type, description, and fields, have been successfully cloned.

Conclusion

In conclusion, this article comprehensively discussed system-defined templates and their distinctions from custom templates. Users have gained insights into the advantages of system-defined templates, such as their predefined workflows and settings. Additionally, the article focused on the significance of the Service Desk Template Interface, integration with external platforms, fulfillment modes, and workflow configurations. Using OvalEdge's Service Desk templates optimizes requests and improves operational efficiency.