Deep Dive Articles
      Back to home
      1. Knowledge Base
      2. Release6.3 Deep Dive Articles
      3. Deep Dive Articles

      Service Desk Templates

      Service desk templates are pre-designed formats that streamline and standardize the service request process. They serve two purposes: generating Service Requests and outlining the request format. They're divided into System and Custom templates.0

      Author license users can use the predefined system templates built into the service desk. They are designed to address common or standard service requests and are default options for handling various requests. System templates come preconfigured with standard fields and workflows, helping streamline the process by providing a ready-to-use solution for common scenarios.

      Access templates by searching for a specific template and reviewing its associated details.

      System Templates

      All Author-licensed users can view Service Desk Templates. Only System Admins, Connectors, or Domain Security Governance Admins (SGA) can modify these templates. Modifications are restricted to mapping Integrations to the template, changing workflow, or changing the template status between Active and Inactive. To create personalized requests, clone the System Templates and use them to generate Custom Templates.  

      Custom Templates 

      Custom templates can be created or customized according to specific needs and requirements. Organizations tailor them to meet their unique needs by adding or removing fields, customizing workflows, and designing the template layout to align with specific processes and requirements.

      Integrations 

      An integration connects the service requests with other applications or tools. It enables smooth communication and data exchange between systems, improving the service desk's functionality and efficiency.

      External Integrations

      External Integration details can be added/edited on the Service Desk Templates page through the Integrations option at the top right corner. Three external integrations are supported: JIRA, Service Now, and Azure DevOps. If no integration information is available, the selected Integration is indicated as "No Integration Information." Click on the integration button at the top right corner of the Service Desk Templates page and in the new window, click the plus icon to add a new integration. 

      Add/Edit JIRA Integration

      To add a JIRA integration tool, include the following details:

      1. Integration Name
      2. JIRA Server
      3. User Name
      4. JIRA API token
      5. Authentication Type (Basic / Bearer)
      6. Version (Cloud / On-Premise> 8.4)

      Everything except the JIRA server field can be changed when editing the JIRA integration.

      1

      Add/Edit ServiceNow Integration

      To add a Service Now integration, include the following details,

      • Integration Name
      • ServiceNow Server
      • User Name
      • ServiceNow token
      • Authentication Type (Basic / Bearer / Oauth)

      Everything except the ServiceNow server field can be changed when editing the ServiceNow integration.

      2

      Adding/Editing Azure DevOps Integration

      To add an Azure DevOps integration, input the following details:

      • Integration Name
      • Host Name
      • Organization
      • User Name
      • Token
      • Authentication Type (Basic / Bearer)
      • API version (7.0 / 7.0 preview / 6.0 / 6.0 preview / 7.1 preview)

      Everything except the Host Name and Organization fields can be changed when editing the Azure DevOps integration.

      3

      Deleting an Integration

      When you delete an integration, the system displays a confirmation message. The deletion process removes all linked mappers. The service desk needs to remap and configure integrations for reintegration.

      4

      System Templates

      All Author-licensed users can view Service Desk Templates. Only System Admins, Connectors, or Domain Security Governance Admins (SGA) can modify these templates. Modifications are restricted to mapping Integrations to the template, changing workflow, or changing the template status between Active and Inactive. To create personalized requests, clone the System Templates and use them to generate Custom Templates.

      Custom Templates

      Custom templates are created by System Admins when the available templates don't meet the organization's needs. They can be made from scratch or cloned from System Templates/Custom Templates. Cloning a system template does not allow the deletion of existing template fields.

      Creation of Custom Templates

      When creating a Custom template, the initial steps involve specifying the template name and description. Then, the Object type for the template must be selected from a range of available options. These Object types include:

      • Generic Objects from Data Catalog (Schema, Table, Table Column, File, File Columns, Report, Report Column, Code, API, and API Attributes)  
      • Governance Catalog (Business Glossary Term, Global Domain, and ROPA Report) 
      • Other (Project, Tag, Data Stories, License Type, Role, Team, and None)

      The Object Type chosen determines the context of the template. If Object Type-None is selected, Service Requests will be created for Objects not associated with predefined Object Types.

      5

      • Once the Object Type is selected, choose the Request Type for the Template. Available Request Types include the following options:
        • New Asset Request 
        • Access 
        • ROPA Approval 
        • Content Change 
        • Object Approval 
        • Privilege Request 
        • Compliance
        • ROPA Processing Activity Approval 
        • Impact Analysis 
        • Crawl/Profile 
        • Build Lineage 
        • Data Quality Issue 
        • Change Term Structure 
        • Other 
      • Selecting the Request Type designs the service desk template for a specific request. If Request Type - Other is selected, it creates service requests with custom request types, offering flexibility for unique needs.
        6


        If the chosen Object type belongs to the Data Catalog category, select a connector type after choosing the request type. The ability to create templates for specific connectors relies on permissions. System Admins can create templates for all connectors. After selecting the connector type, choose the corresponding connector name.
        Note: Connector Admins can create custom templates for connectors with administrative privileges.

      • In scenarios where a governance catalog type is selected, after the request type, choose a Domain. Like with connectors, the ability to create templates for specific Domains depends on permissions. System Admins can create templates for all Domains. After selecting a Domain, choose a Category and a Subcategory if needed.

      Additional Settings:

      Use Additional Settings to edit headings and tooltips for each phase in a service request. The JSON editor allows you to make changes, while the Custom Template for Additional Settings allows only the label and tooltip to be adjusted.

      7

      Template Fields

      Template fields are displayed after entering the Connector or Domain details (in the case of Object Type - Others, after choosing request type) and configuring Additional Settings. The following are reserved keywords and cannot use the same field name for any other custom templates. 

      • Requested By
      • Requested for 
      • Summary
      • Description
      • Priority
      • Service Request Id
      • Service Request Link
      • Selected object type as the primary field.

      All custom templates have these fields by default.
      8

      Field 

      Field Description

      Order 

      Order is the arrangement of fields. Mandatory fields have a predefined order. Adding a new field gets the following number in the sequence.

      Field type 

      Multiple field types are available for choosing:

      • Additional Fields, Business Description, Business Glossary, Checkbox, Database, Date, Domain, Dropdown, File, File Column, File Folder, Input text, New Business Glossary Name, New Report Name, New Table Column Name, New URL, OvalEdge Author Roles, OvalEdge Contributor Roles, OvalEdge Roles, OvalEdge Teams, OvalEdge Users, OvalEdge Viewer Roles, Product, Project, Query, Radio Button, Report, Report Column, Report Group, ROPA, ROPA report, S3 Privileges, S3 roles, Schedule, Schema, Snowflake applications, Snowflake privileges, Suggestions, Table, Table column, Tags, Technical Description, Terms, Text Area, and User Snowflake roles

      Field Label 

      The name of a field can be changed as preferred.

      Options 

      This field becomes visible when selecting the field type (Drop-down, Checkbox, or Radio Button). The dropdown allows you to select one option among three types: API, Custom list, or Database.

      Placeholder Text

      Customize the placeholder text for all field types except "Dropdown" and "Checkbox." 

      Tooltip 

      Edit tooltip descriptions to offer more guidance or information about a specific field.

      Multiple Values

      When applicable, enabling multiple values lets you choose more than one value in the service request.

      Primary Field

      Only object types can designate fields as primary fields. In the Approval workflow, governance roles assign approvers based on the primary field. If an object type like projects or tags lacking governance roles is chosen as the primary field, OE_Admin automatically becomes the default approver.

      Custom Options 

      Using a JSON editor, you can adjust the appearance of a field type during different phases of the Service Request cycle, which includes several phases.

      • Pre-creation phase
      • Creation phase
      • Review phase
      • Approval phase
      • Additional info phase
      • Fulfillment phase

      Note: Mandatory fields cannot be changed, so custom options cannot be modified. Adjustments can be made to custom options as needed for newly added fields.

      Custom options for template fields:

      Field Behavior: In the Field Behavior, configure the field type to be viewable, editable, or mandatory during different phases of the Service Request cycle.

      For example, The template field "Requested By" is not visible, editable, or mandatory in the pre-creation phase but is configured to be visible in the creation phase.

      If a template field depends on another template field, the dependency's configuration can also be done in Field Behaviour. 

      Field Code: The JSON Field Code of the dependent template field can be selected from the “Field Codes” for this purpose.

      Configure Validations: Template fields can be configured with restrictions such as max length, min length, character type, date, etc., through “Configure Validations.”

      9

      Fulfillment

      There are two fulfillment methods for a Service request:

      1. Manual Fulfillment: Approvers make the changes manually as requested by the requestor.
      2. Automatic Fulfillment: Job logs capture requested changes and execute them automatically without human intervention.

      Fulfillment options for Automatic fulfillment depend on specific Request and Object type combinations. A drop-down menu shows the relevant options based on the Request and Object Type.

      Automated Fulfillment

      Request Type

      Object Type
      • New Asset Request
      • Access Request
      • Content Change
      • Object Approval
      • Privilege Request
      • Change Term Structure
      • Data Catalog (Schema, Table, Table Column, File, FileFolder, File Column, Report, Report Column, Code, APIs and API Attributes). 
      • Others (Project, Tags, License Type, Role, and Team).
      • Governance Catalog (Global Domain,  Business Glossary, and ROPA Report).

      Bring Your Own Fulfillment (BYOF)

      Automatic fulfillments are options generated by the system automatically. System Admins can create custom fulfillment jobs for specific needs. Service Desk templates let OE_Admins create the classes using OvalEdge's framework.

      • Setting up custom fulfillments involves configuring criteria such as request type, object type, connector type/domain type, and connector ID/domain ID. Once added, these custom fulfillments can be accessed in the Fulfillment job details.
      • Partial fulfillments at the approver level require custom fulfillment jobs because system-generated fulfillment jobs don't support this feature.
      • For instance, consider a content change request for tables with four approvers. Using custom fulfillment jobs, specific changes can be made as each approver approves the request:
        • When the first approver approves, the business description is modified.
        • When the second approver approves, the technical description is updated.
        • When the third approver approves, associated tags and terms are adjusted.
        • When the final approver approves, custom fields are altered.

      Integrations

      External integration tools such as JIRA, Service Now, and Azure DevOps play two roles in the workflow. They can act as approvers for service requests or track these requests from OvalEdge using the respective external tool.

      • When setting up an integration system, specify the type of issue in the Integration tool. Fill in specific required fields to add an integration to a template.
        • Integration Name
        • Description
        • Integration System
        • Integration Project
        • Issue type

      A sample Integration configuration:

      10

      Mapping Integrations to a Template

      • Mapping the Approved and Rejected Status is necessary when using Integration. For example, with JIRA as the Integration System, Approved Status can be "Done," and Rejected Status can be "In Progress" or "On-Hold." Remember, the Status is case-sensitive and must match exactly the External Integration tool's wording.
      • After establishing these specifics, link Template fields to corresponding fields in the Integration tool. To ensure proper integration with JIRA, match the "Summary" template field with the JIRA field of the same name when selecting JIRA as the integration system. This way, the Summary entered in the Service request will create a ticket in JIRA with the same Summary. A ticket is made in the External tool when the service request is approved and the External Integration tool approves it.
      • It is also possible to configure integrations for System templates.

      Workflow

      Workflows at Service Desk Template 

      Workflows in service desk templates specify approvers. Each template allows for creating a new workflow or using an existing one to approve service requests.

      • To create a new workflow, one must provide a name and description. Then, actors who will approve the request must be selected. If a new workflow is created at the template level, it can only be applied to the template.
      • After choosing the scope, enter a mandatory description. Then, add actors to the workflow. If you need only one actor, fill in the "Final Action By" field. If you need multiple actors, add various actions with different actors.
      • Next, select an Action from the dropdown, and the corresponding Status is automatically filled in. For example, if the Action is 'Approve,' the corresponding Status could be 'Approved.' Here are the available Actions and their corresponding Statuses: 
        • Analyze, Analyzed
        • Approve in Azure DevOps, Approved in Azure DevOps
        • Approve in JIRA, Approved in JIRA
        • Approve in ServiceNow, Approved in ServiceNow
        • Check Authorization, Authorized
        • Check Feasibility, Feasibility Checked
        • Check Permission, Has Permissions
        • Discuss, Discussed
        • Final Approval, Final Approved
        • Give Feedback, Feedback Given
        • Review, Reviewed
        • Schedule, Scheduled
        • Test, Tested
        • Validate, Validated
        • Verify, Verified
      • If the approvers in the approval workflow for the template is given with one actor, the status will be automatically resolved upon approving or rejecting the ticket. 
      • After selecting the Action, choose the Actor. Different types of actors can be added, such as: can be added,
        • Roles
        • Teams
        • External Integrations
          • Jira
          • Azure DevOps
          • ServiceNow
        • User
        • Governance Roles
          • Steward
          • Custodian
          • Owner
          • Domain Steward
          • Category Steward
          • Parent Steward
        • Story Author
        • Project Admin
        • User Data Control Manager
        • User Data Governance Manager
        • User Manager
      • Once an actor is designated, a Service Level Agreement (SLA) can be configured. Including an SLA is optional; if selected, the actor will receive notifications if the SLA's specified timeline is breached. Consolidated pre-violation notifications and post-violation notifications are received by the approvers.
      • To monitor a service request via an External Integration tool, select the Integration type from a Drop-down menu.
      • A request can undergo auto-fulfillment at an Approver level, provided the combination of the request type and object type permits auto-fulfillment. To do this, choose the Fulfillment option in the "Action level Fulfillment" dropdown. 
        • For example, suppose three actors are involved in a workflow, and the second actor is responsible for auto-fulfillment. In that case, the requested changes from the requester will be executed after approval by the second actor, regardless of the third approver's action.
      • After completing all the workflow stages, you can view the fulfillment, close request action, status, and actors involved. If you choose automatic fulfillment, you will only see the status. However, if you choose manual fulfillment, you will see two actions and their corresponding statuses. Please note that the final fulfillment and close request information cannot be edited or viewed in the Security module - it's only available for reference purposes.
      • A service request usually stays open for approval until it is approved by all involved parties, referred to as 'actors' in this context. However, with the admin supersede feature active, a request can be superseded by the System Admin, bypassing other approvers.
      • The admin supersede doesn't apply if an actor in the workflow is an external integration tool. It only works for other actors.
      • When choosing an existing workflow, you can use it as it is or edit and save it. Any changes will affect all linked templates. Only workflows labeled "Template" can be altered; those labeled "Global" cannot be changed.

      Configuring Workflow Action and Status

      The Workflow Actions and Status can be configured from System Settings.

      11

      • Upon clicking the + icon at the top right corner, a new popup window appears where the admin (ovaledge.role.admin) can add an action and its corresponding status by providing the following details:
        • Action Name
        • Status
        • Color
        • Description
        12

      • After updating the Action & Status, the admin can assign these actions in the associated workflow for the required template.
      • When a request is raised, the first approver can see the Action Name and approve the request. After the first approver approves the ticket, the requester can see the Action Status in the ticket summary page, along with the color provided during the creation of the Action Name.
      • The description provided by the admin appears as a tooltip when users hover over the corresponding status of a service request. 
      • In addition to the custom description set by the admin, OvalEdge provides predefined descriptions for system-defined statuses to highlight their need and importance.
      • All Action and Status labels can be edited, and the changes will be reflected in service requests accordingly.

      System Status

      In Service Desk, by default, some mandatory statuses cannot be disabled. Here is the list of those statuses and their details:

      13

      1. Draft - A service request in the Draft status is incomplete and not yet submitted for processing. It allows users to save progress, make edits, or review details before submission.
      2. Awaiting Action - ‘Awaiting Action’ status indicates that the service request has been submitted by the requester, and it is waiting for the first approver to take action.
      3. Rejected - The 'Rejected' status indicates that the service request has been rejected by an approver. The request can either be reopened or modified and reopened by the requester.
      4. Expired - The 'Expired' status indicates that the service request is no longer valid due to surpassing its defined timeframe or inactivity. It cannot be processed further but remains for reference. This status typically occurs for access requests with an expiration time.
      5. Deleted - The 'Deleted' status indicates that the service request has been withdrawn by the requester.
      6. Resolved - “Resolved” status indicates that a service request or change has received approval from all required approvers in the system. This system-defined status is shown prior to the start of the fulfillment process.
      7. Reopened - The “Reopened” status indicates that the requester has reopened a previously rejected or fulfillment-failed service request, which will now restart the approval process from the beginning.
      8. Request Closed - The "Request Closed" status indicates that a service request has been fulfilled and no further action is required.
      9. Fulfillment In Progress - “Fulfillment In Progress” indicates that the service request has been approved, and the service request is actively being processed, and the required actions or tasks are underway to complete the requested service.
      10. Fulfillment Successful - “Fulfillment Successful” indicates that the service request has been completed and delivered as expected.
      11. Partially Fulfilled - “Partially Fulfilled” indicates that the service request has been partially completed, with some tasks or actions successfully fulfilled while others remain pending or incomplete.
      12. Fulfillment Failed - ‘Fulfillment Failed’ indicates that the service request could not be completed successfully due to an error or issue during processing.
      13. Approved - The 'Approved' status indicates that the previous approver has approved the service request and sent it to the current approver for next action.

      Accessing Workflow from Security

      Details of all Workflows can be found in Security. Author Licenses can see all the Workflows but cannot create, edit, or delete them. Only System Admins or Connector/Domain SGAs can make changes to Workflows.

      • The different columns on the Workflow page are
        • ID
        • Approval Workflow
        • Description
        • Scope
        • Template Type
        • Service Request templates count
        • Created By
        • Created On
        • Updated By
        • Updated On
      • Workflows with a Template scope are viewable but not editable here. Only workflows with a Global scope can be edited.
      • Template scope workflows allow viewing, but details like Fulfillment, Close Request, and External integration info are unavailable here. They are only accessible at the Template level.
      • Workflows created from this page can only have a "Global" scope. Only workflows from this page can be deleted; system workflows and custom workflows linked to any template cannot be deleted.
      • Workflows can be set up for System templates. Once added, they can be edited anytime, even if the template is Active.

      A sample workflow: 

      14

      15

      Edit/ Delete Templates

      Status of Template

      To change a custom template created from scratch from "Draft" to "Published" status, one must add all the required details. After adding all the necessary information, the template will become "Published." It cannot be modified except for making changes to Integrations or Approval Workflow.

      • Only moving templates from the "Published" state to the "Active" state is possible. Templates that share the same components with an "Active" template, such as Request Type and Object Type, cannot be activated.
      • Once a service request is created using a custom template, it cannot be changed back to "Draft" or deleted.

      Editing Field Labels

      Few fields of a Service Desk template can be edited, provided there are no pending service requests for the template and its status is Inactive. The editable fields in this scenario are:

      • Field Label
      • Placeholder Text
      • Tooltip
      • Custom Options

      Once changes are made to the template and the admin makes the template Active, the new service requests will reflect the updated fields.

      System Settings

      • Key: servicedesk.template.fields.limit
        This sets the highest number of fields allowed in a service desk template. The default is 20, and the maximum is 50.
      • Key: servicedesk.template.approvalworkflow.limit
        Determines the maximum number of actors allowed in the workflow for a service desk template. The default is 10, and the maximum is 20.
      • Key: servicedesk.approvalworkflow.team.role.limit 
        Specifies the number of team/role members needed to approve the request if all members are required. The default value is 5, and the maximum value is 20.

      Copyright © 2024, OvalEdge LLC, Peachtree Corners, GA, USA.