Templates (System & Custom)
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 the 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.
Custom templates allow organizations to tailor service request forms to meet specific business needs that aren't fully addressed by default templates. They provide the flexibility to define unique workflows, fields, and approval processes aligned with internal policies, data governance standards, or department-specific requirements.
Request Type Selection for Template Creation
When creating a new service desk template, the request type must be selected first. This is because the fulfillment type—whether manual or automatic—is predefined based on the selected request type.
Certain request types support only manual fulfillment, meaning there are no automatic processing options available. By choosing the request type at the beginning, users are immediately informed about the nature of fulfillment associated with that request.
Additionally, for request types that support automatic fulfillment, the system provides extra information highlighting which object types are eligible for automatic processing. This upfront clarity helps users design templates more efficiently and avoid misconfiguration.
Click on the plus (+) icon to create a new service desk template.
Choose the Request Type for the Template.
After selecting the Request Type, users can see whether the request supports automatic fulfillment or if only manual fulfillment is available.
Template Details
The Template Details provide basic and necessary details of the template, such as the following:
Description
Request Type
Object Type
Fulfillment Mode
Fulfillment Instructions
Further information, such as Template Version, Last Updated Date, Last Used Date, Total, and Pending requests, is also provided in this tab.
The Object type for the template must be selected from a range of available options. These Object types include:
Objects from Data Catalog (Schema, Table, Table Column, File, File Columns, Report, Report Column, Code, API, API Attributes)
Generic Object - Choosing this will allow selection of all Data Catalog object types in a single field.
Governance Catalog (Business Glossary Term, Global Domain, ROPA Report, and Processing Activity)
Other (Governance App, Data Story Zone, Data Story, Project, Tag, 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.
If the chosen Object type belongs to the Data Catalog category, select a connector type. The ability to create templates for specific connectors relies on permissions. System Admins can create templates for all connectors, while Security Governance Admins (SGAs) can create templates only for the connectors they have access to. After selecting the connector type, choose the corresponding connector name.
In scenarios where Domain or Business Glossary is selected as Object Type, the user has to select Domain, similar to selecting Connectors for Data Catalog Object Types. System Admins can create templates for all Domains, while Security Governance Admins (SGAs) can create templates only for the Domains they have access to. After selecting a Domain, choose a Category and a Subcategory if needed.
Fulfillment
There are two fulfillment methods for a Service request:
Manual Fulfillment: Approvers make the changes manually as requested by the requester.
Automatic Fulfillment: Job logs capture requested changes and execute them automatically, eliminating the need for 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:
New Asset Request
Table, Table Column, Report, Report Column, Business Glossary, Project, Tag, Data Story Zone
Access
Schema, Table, File, Report, API, Global Domain
ROPA Approval
ROPA Report
ROPA Processing Activity Approval
Processing Activity
Content Change
Schema, Table, Table Column, FileFolder, File, File Column, Report, Report Column, API, API Attribute
Object Approval
Business Glossary
Privilege Request
Role, Team, License Type
Change Term Structure
Business Glossary
Fulfillment Instructions
Admins can define fulfillment instructions for service requests at the service desk template level. By default, instructions indicate whether the request will be fulfilled automatically or requires manual action by approvers. If no fulfillment instruction is necessary, the field can be left blank in the template, and no instruction will appear in the service request.
Bring Your Own Fulfillment
Automatic fulfillments are options generated by the system automatically. System Administrators can create custom fulfillment jobs to meet specific needs. Service Desk templates enable OE Admins to create classes using the application'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.
Template Fields
Template Fields define the form fields displayed to users when they raise new service requests using a selected Service Desk Template. These fields help collect the necessary information for that type of request.
The following are the columns in the Template Fields section:
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:
Database, Schema, Table, Table Column, File, File Column, Report Group, Report, Report Column, Code, Domain, Business Glossary, Project, New Table Name, New Table Column Name, New Report Name, New Business Glossary Name, Business Description, Technical Description, Additional Fields, Schedule, Tags, Terms, Date, Dropdown, Checkbox, Radio Button, Input Text, Text Area - Plain Editor, New URL, User Snowflake Roles, Snowflake Privileges, S3 Roles, S3 Privileges, File Folder, OvalEdge Users, OvalEdge Teams, OvalEdge Roles, OvalEdge Author Roles, OvalEdge Viewer Roles, Product, Snowflake Applications, Text Area - Rich Editor, Category, Sub Category, Ropa Report, Ropa Processing Activity, New Report Column Name, New Project Name, New tag Name, OvalEdge Viewer Users, OvalEdge Author Users, API, API Attribute, Data Story, Generic Object, Primary Object GUIDs, Upload File, Master Tag, Parent tag, Detail Description, Policy, Data Classifications, Story Zone Name, and Governed Data Query.
Field Label
The name of a field can be changed as preferred. The Field Labels of a Service Desk Template should be unique. There can be multiple fields of the same field type, but they cannot have the same field label.
Primary Object Type
The Primary Object Type defines the object on which the template is based. For example, if the Object Type is chosen as Table, the primary object type is set to Table by default. This can be changed, but it can be attributed only to objects within the application. In the workflow, if governance roles are selected as approvers, the governance role of the selected primary object type is considered in the workflow.
Field Properties
The 'Field Properties' column defines the specific characteristics and behavior of each field included in a service desk form. These properties control how a field appears and functions, such as whether it is mandatory, read-only, hidden, or has predefined default values.
For any service desk template, there are certain mandatory fields (non-removable fields):
Requested By - It displays the name of the user who initiated the service request.
Summary - It displays the summary of the service request.
Description - It provides a detailed explanation of the service request.
Priority - It indicates the priority (low, medium, high) of the service request.
Service Request ID - It is a unique identifier automatically assigned to each service request submitted through the system.
Service Request Link - It is a URL or hyperlink that directs users to a specific service request form or ticket in the system.
Although the Description and Priority fields are non-removable, they can be hidden through the Field Properties of the template field. Other than these two mandatory fields, none of the other fields can be modified for any template.
Modifications can be made only for newly added fields.
The following are reserved keywords and cannot be used for the same field label in any other custom templates.
Requested By
Summary
Description
Priority
Service Request Id
Service Request Link
Selected object type as the primary field.
Simplified Template Field Management
The simplified UI streamlines the configuration and modification of field-level settings in service request templates, enhancing the overall user experience. Users can edit the field properties of templates.
The ‘Edit’ Field Properties section has the following fields:
Field Properties
Field properties define the specific configuration and behavior of each field within a request form. It has the following sections:
Field Details: The 'Field details' section allows administrators to define specific attributes for each input field. This includes setting a tooltip (a short help message that appears when users hover over the field), maximum and minimum character limits (to control the input's length), and a placeholder text (a sample or guiding text displayed inside the field before the user enters data). These settings help ensure that user input is consistent, meets validation rules, and provides guidance on completing the form correctly.
Configuration for each phase: The 'Configuration for Each Phase' section enables administrators to define and customize the fields that appear during each phase of the service request. Admin can configure whether a field is visible, mandatory, or editable in each phase. A field can be made mandatory only if it is visible and editable. Similarly, a field can be made editable only if it's visible.
Depends On
The customized JSON code configured for a template now appears under the Depends-On tab. This enhancement provides better visibility and management of dependency logic defined for template fields, enabling administrators to review and update conditional configurations easily.
Dropdown Options
The 'Dropdown Options' allows administrators to define a list of predefined selectable values for a particular field when configuring a service desk template. This enables users to choose from a consistent set of options, such as priority levels. This tab is enabled only for field types that have dropdown options.
File Upload in Service Requests
To enable file uploads through a service request, follow these steps:
Add the "Upload File" Field
Add the “Upload File” field to a custom service request template.
Save the template to allow users to upload files.
Configure the File Upload Path Before uploading files, the admin must configure the File upload path under System Settings. Supported storage options include AWS, Azure, and NFS.
File Storage and Retrieval
Uploaded files are stored in the configured connector.
When users download files, the data is retrieved from the same connector.
File Upload Limits
Total file upload size: 10 MB.
Individual file size limit: 2 MB.
File Management
The uploaded file details are displayed in the service request.
Users can remove files if needed.
Only certain file types are allowed for upload. The allowed file type list is provided in the System Setting - allowed.file.types.for.file.upload
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 the application using the respective external tool.
When mapping an integration system, specify the type of issue in the Integration tool. Fill in specific required fields to map an integration to a template.
Integration Name
Description
Integration Project
Integration System
Issue type
A sample Integration configuration:
Map 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.
To enhance flexibility in managing service requests, a system template field called "Service Request Source" can be utilized. This is a dropdown with a default option of OvalEdge. It can be mapped to external integrations as Label, Parent, or Source, and can be edited or removed at the template level as needed.
Workflow
The Workflow is used to define and manage the approval process that a service request must follow. It is a key part of governance operations by routing requests through the appropriate stakeholders. Users have the option to create a new workflow or select and edit an existing one.
Workflow Action & Status
It is also possible to configure the Actions and Status from System Settings.
Upon clicking on the + icon at the top right corner, a new popup window appears where the super admin (ovaledge.role.admin) can add an action and its corresponding status by providing the details below.
Action Name
Status
Color
Once these Actions & Status are updated, the Super Admin can assign these Actions in the Associated Workflow for a required template.
Upon raising a request, the first approver can see the Action Name and Approve the request.
The Requester can see the Action status on the ticket summary page, along with the color provided while creating the Action Name, after the first approver approves the ticket.
If the approvers in the approval workflow for the template are 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:
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. The approvers receive consolidated pre-violation notifications and post-violation notifications.
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 requestor will be executed after approval by the second actor, regardless of the third approver's action.
After completing all the workflow stages, users can view the fulfillment, the close request action, the status, and the actors involved. If users choose automatic fulfillment, they will only see the status. However, if they choose manual fulfillment, they 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 until approved by all involved parties, referred to as 'actors' in this context. However, with the admin supersede feature active, a request can close upon approval from 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, users 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.
Workflow in Service Desk Templates
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 users need only one actor, fill in the "Final Action By" field. If they 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
Access 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
Name
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:
Template Properties
Template properties are configurable attributes that define how a service request form behaves and appears to users.
Template Configurations
Template Configurations define the structure and behavior of how service requests are created, processed, and resolved. These configurations help standardize request handling across the organization by customizing templates to suit specific governance and data management needs.
Enable Close
The "Enable Close" checkbox field controls whether users (typically requesters or assignees) are allowed to close the request created using that template manually. When this checkbox is enabled (checked), the request form generated from this template will include an option to close the request manually. If it is disabled, there is no option to close service requests.
Allow Cloning
The "Allow Cloning" checkbox is a setting that controls whether service requests can be duplicated (cloned) by users. When this box is checked, users are allowed to clone service requests created from this template.
Enable Reopen
The "Enable Reopen" checkbox governs whether a requester can reopen a ticket after it has been rejected or after fulfillment fails. When this option is checked and an approver rejects the ticket: 1. The requester is given the ability to reopen the ticket. 2. They can either add more details or correct existing information before resubmitting.
Clone Dropdown
This configuration is custom-defined with preset parameters. Even if enabled, it may not reflect changes directly in the service request behavior. For further details, please get in touch with the OvalEdge team.
Enable Stepper
The Enable Stepper checkbox controls whether your service request form is displayed as a multi-step wizard with details such as completed phases, current phase, and pending phases.
Enable Refer Back
The "Enable Refer Back" checkbox enables approvers to send a ticket back to a previous approval stage or refer back to the requester. Once enabled, approvers will see a "Refer Back" action in the ticket's dropdown menu (alongside options like Approve or Reject), which routes the request back to an earlier approver for revisions or asks the requester to provide additional information.
Enable Save as a Draft
The "Enable Save As Draft" checkbox allows users to save their request forms as drafts before submitting them. When this option is enabled in a template, users filling out the service request based on that template can choose to save their progress and return later to complete or discard it.
Status Description
This configuration is custom-defined with preset parameters. Even if enabled, it may not reflect changes directly in the service request behavior. For further details, please get in touch with the OvalEdge team.
Show Help Context Keys
This configuration is custom-defined with preset parameters. Even if enabled, it may not reflect changes directly in the service request behavior. For further details, please get in touch with the OvalEdge team.
Action for Fulfillment
The Action for Fulfillment checkbox designates a field to be part of the request's fulfillment phase—either to trigger automated actions or guide manual tasks, ensuring that crucial information or actions aren't missed once approvals are complete.
Allow Access Extension
This configuration is custom-defined with preset parameters. Even if enabled, it may not reflect changes directly in the service request behavior. For further details, please get in touch with the OvalEdge team.
Save Withdraw Request
The “Save Withdrawn Request” checkbox controls whether withdrawn service requests are retained in the system after being withdrawn. When checked, withdrawn requests are saved in your ticket history, preserving their details and metadata within the system.
Enable Approval History
The "Enable Approval History" checkbox toggles whether to record and display a history of approvals for that template. When enabled, each approval or rejection on a Service Desk ticket under that template will be tracked and recorded.
Make Comments Mandatory
The “Make Comments Mandatory” checkbox ensures that approvers enter comments before taking any action. If this configuration is enabled, approvers should mandatorily provide comments before approving, rejecting, or referring back a request.
Display Grouped Object Count
The “Display Grouped Object Count” checkbox in the Template Configuration controls whether the system shows the number of objects grouped under each service request template when users are working with the Access Cart or raising multiple requests simultaneously.
Autopopulate Details To Other Requests
This configuration is custom-defined with preset parameters. Even if enabled, it may not reflect changes directly in the service request behavior. For further details, please get in touch with the OvalEdge team.
Forward To
The 'Forward to' allows the current approver to skip approvals of subsequent approvers or move it directly to fulfillment.
Phases and Labels
The following are the different phases included in the Templates Properties:
Selection Phase: In the selection phase, objects are selected for the service request.
Creation Phase: In the Creation phase, the requester fills in and submits all required details for the service request.
Approval Phase: In this phase, the approver approves or rejects the service request. Service Requests can be edited by the requester or approver if enabled for certain fields.
Additional Information Phase: This phase occurs when the service request is rejected or if the approver has sent back the request to the requester for additional information.
Fulfillment Phase: The 'Fulfillment Phase' refers to the stage where the actual resolution or completion of a service request takes place. During this phase, assigned users or teams carry out the necessary actions to fulfill the request—such as implementing changes, updating data, granting access, or resolving issues—based on the details provided in earlier phases, including Initiation and Approval.
Clone Template
To simplify the template creation process, users can clone an existing template instead of creating one from scratch. This allows for a quicker setup by reusing existing configurations.
Steps to Clone Template
Go to Administration > Service Desk Administration > Service Desk Templates, and a list of Service Request Templates appears.
Select the Domain Data Access Request template and navigate to Nine Dots > Clone Template.
Enter the clone template name, then click Save.
A success message appears. Click on the template name to navigate to the cloned template.
Now, an existing template is cloned.
Update the Domain name from the drop-down list.
Add the associated workflow.
Go to Nine Dots > Active.
Then again, go to Nine Dots > Publish.
Now, the users can perform all the operations available in the original template.
Edit/Delete Templates
Template Version
The 'Service Desk Template Version' refers to the version control mechanism for service desk templates. Each time a template is modified—whether it’s a change in fields or configurations—it is updated as a new version. This allows administrators to manage and track changes over time, ensuring that any updates to the template do not affect previously submitted or ongoing service desk requests. Changes to the workflow or Ticketing System Integration do not change the version of the template.
Template Availability/Activation
The ‘Template Activation’ refers to the availability(Active or Inactive) of a Service Desk template. When a template is marked as Active, it becomes available for users to select and use when raising service desk tickets. Conversely, when a template is set to Inactive, it is hidden from the user interface and cannot be used for creating new requests, although existing tickets based on that template remain unaffected.
Template Status
The 'Status' field indicates the current state of the template—either Draft or Published.
In Service Desk Administration, administrators can create a draft version of an already published service request template. While editing the draft, the existing published version remains available for raising service requests. Submitted requests retain the template version used at the time of submission, while new requests reflect the latest published version. Once the draft is published, it replaces the previous version, which becomes inaccessible. Service requests created using earlier template versions cannot be cloned if template fields have changed.
Last updated
Was this helpful?