1.2.5. Working on a Request¶
Once a Technician decides to work on a Request, he heads to the Details View of the Request. There he/she uses the product features and tools to resolve and close the Request.
1.2.5.1. Request Details View¶
The Request Details view organizes and manages all information related to a Request. Each Request has its own Details View having features that Technicians use to resolve a Request.
To open the Details View
Go to Request List View.
Scroll down to a Request that you want to open. Click on the name of the Request, which is adjacent to its ID. The Request Details View opens. Each Request has its own Details View.
The Details View is a dynamic interface with the following features:
Section-A houses the Subject and Description.
Section-B & C houses the Classifiers.
Section-C also houses the Search KnowledgeBase feature.
Section-D houses five functions:
Work
request information
Section-E is Task column which is a sub-feature of the Work tab.
Section-F shows you the requester details.
Section-G houses the following options:
Close this Request
Action Menu:
Mark as Spam
Mark as Purchase Request
Watch/Unwatch
Send Feedback
Scenario
Split
1.2.5.2. Modifying Request Subject and Description¶
You can modify the Subject and Description of a Request. Below the
header title (section-A in rmf-16
) shows the ID of the Request. Next
to the ID is the subject line of the Request. It is supposed to give you
a short description of the Request, and next to it is the Edit Icon for
editing the Subject and Description.
Go to the Details View of the Request.
Click on the Edit Icon.
A dialog box opens. There you modify the Subject and Description and hit Update.
1.2.5.3. Requestor Info and Other Requests of a Requestor¶
A Technician can view Requestor information and other Requests created by the Requestor from the Details View of a Request.
Go to the Details View of a Request
Hover your mouse over the Requestor info section of the page.
A window pane will open where you can access the following information.
Other requests created by the requester.
Profile of the requester.
Assets assigned to the requester.
Note
In the user Profile tab (
rmf-18.2
), you can also view the values of Custom User Fields.
1.2.5.4. Classify Requests¶
Motadata provides many avenues to classify a Request. Go to the Details View of a Request, and there you get the following ways:
Status: Every Request has a life-cycle in the system. Setting the Status tag shows the stage at which the Request is in its life-cycle. There are seven Predefined statuses in the system: Open, In-Progress, Pending on Requester, Pending in Approval, Pending on Technician, Resolved and Closed. Other than In Progress, you cannot modify any of the predefined statuses.
The status Pending in Approval is set automatically by the system whenever a Request goes through the Approval process. This status cannot be set manually.
You can add custom statuses for which you need Admin rights. For example: you have a custom status called hold.
Custom Tags: These are additional tags that a Requester and Technicians can provide. This is a way to categorize a Request when default options are not enough. For example: you can add a tag Antivirus to all Requests related to antivirus renewal.
Identified as Problem: This label classifies the Request as having a related Problem. The Problems can be viewed in the Relations tab.
Importance: A Request can be categorized based on importance in the following ways:
Priority: Setting this label shows the magnitude of the Request in the system. The Priority labels are system-defined. You can choose whether to set Priority manually or automatically using the Priority Matrix feature in Admin (refer Administration Manual).
Urgency: Setting this label helps Technicians to ascertain the response time for the Request. These are predefined labels that are immutable, and they are Low, Medium, High, and Urgent.
Impact: Setting this label shows where the Request has its effect which is either on User, Department or Business.
Service Level Agreement: SLA determines the Response Time and Resolution Time after considering Priority (other conditions in case of custom SLA). It also determines the escalated action when a time condition is violated. This generates the following data points about a Request.
Overdue Status: Tells whether any of the SLA conditions are violated or not.
Due-Date: It reminds Technicians about the due date.
Estimated Time: It tells the estimated time of resolution of the Request in minutes. A Technician can modify this, but it doesn’t changes the SLA conditions.
Support Level: All Technicians are grouped into four Tiers based on their expertise and experience. Setting this tag shows which Tier the Request belongs.
Escalation Level: This is the number of times escalated actions were taken based on SLA.
Place: A request can be classified based on the associated physical locations which are:
Note
Below both fields have predefined values (as a drop-down list) set by the Administrator.
Department: If the Request is related to a particular department, then this field is set to that department. A Technician can manually set the department field if needed.
Location: If the Request is related to a particular location, then this field is set to that location.
Source: It shows the medium used to create the Request. The field is automatically set by the server based on how it was created. For example: all Requests created via email have the source set to Email.
Category: It is the primary method to categorize the Request. Learn More.
Technician Group: The product allows grouping of Technicians into groups. Setting this field shows which group the Request belongs.
Approval Status: This classifies the Request based on the Approval stage. Learn more about Approval.
Reopen Count: This label shows how many times the Request has been opened after getting close. The tag appears when a Request gets reopened for the first time.
Requestor Account: It shows the associated Requestor Account. Learn more about Requestor Accounts.
Template: If the Request was created using a Service Item (created from a Service Catalog Template), then the name of the Template is shown. Learn more about service-catalog.
CC Emails: The technician can keep a person in loop for all the notifications generated by the ticket.
1.2.5.5. Linking Knowledge with a Request¶
It is crucial for a Technician to resolve a Request as fast as possible, which is why information is made available through Knowledge in the Details View.
You can use the Search Knowledge to perform a search of the Knowledge. You could find related information which you can link it with the Request.
Follow the detailed steps below to use the option:
Click on Search Knowledge opens a dialog box with a giant search bar.
Type your keyword in the search bar and press enter.
Matched Articles/FAQs populate below the search bar.
You can preview an Article/FAQ by clicking on it.
Select an Article/FAQ and click on Link. To link multiple Articles/FAQs, you have to repeat the above process for each one.
You can view the related Articles/FAQs of a Request under the Relations tab.
1.2.5.6. Communication, Collaboration, and Resolution¶
Motadata has functions that allow Technicians to gather information through collaboration and communication and use it to resolve a Request. The Work tab in the Details View of a Request has those functions.
Work tab shows all the work and communication done for a Request. The section is also referred to as Resolution section. In here you can perform the following actions:
Note
Apart from Diagnosis, everything else is shown as part of a unified thread.
Ask Requester: You can directly communicate with the Requestor from the Details View using this option. Whatever you communicate gets added to a unified thread. The comments of the Requester also get added to the thread.
The Requester gets an email notification on every message you post and vice-versa (Requestor and assigned Technician are the default recipients for email notification). The Requestor can reply to the emails and the replies are added to the comment thread.
A Requestor can also comment in the Details View of a Request from the Customer Portal. Where he/she can specify a Technician’s name (other than the assigned Technician) as @tachnician_name in the message body, and the mentioned Technician/Technicians get notified via email.
Yon can use a template to insert a canned response in the text field. Click on Insert from Template , which opens a dialog box from where you can search and add a template.
Learn how to add a Response Template.
Collaborate: You can collaborate with other Technicians. You can start a message thread which is visible to people who has access to the Technician Portal. You can notify a Technician my mentioning his/her name as @technician in the message body. This is an immutable action.
Add Note: This option allows you to add additional information about the Request so that others can view the same. You can attach files along with the textual information. This is an immutable action.
Custom rules set by an administrator might ask you to add a Note while doing the following operations:
Assigning a Request.
Changing Department of a Request.
Changing Category of a Request.
Setting a new Due Date of a Request.
Please refer the Administrator Manual to know more about Custom Rules for Requests.
1.2.5.6.1. Add Diagnosis¶
You can add a diagnosis statement in the Details View under Work tag.
The Add Diagnosis option allows you to add an inspection of the related problem. The Diagnosis statement sits on top of the pane with a different color scheme. You can add only one Diagnosis statement per Request. You can modify the diagnosis statement after adding one.
1.2.5.6.2. Add Solution¶
You can add a Solution statement in the Details View under Work tag. You write your solution in the Add Solution section. Along with textual information, you can attach files and can even add links to Knowledge posts.
When you add a solution, you get a prompt asking you to resolve the Request.
Yon can use a template to insert a canned response in the text field. Click on Insert from Template , which opens a dialog box from where you can search and add a template.
Learn how to add a Response Template.
1.2.5.6.3. Resolve Rules¶
Custom rules set by an administrator might prevent you from resolving a Request unless you fulfill the set conditions. Rules are in regards to:
Minimum user interaction with the Request
Mandatory fields.
The state of the Request.
Please refer the Administrator Manual to know more about Custom Rules for Requests.
1.2.5.7. Add Relations¶
Motadata helps Technicians to build contextual information by building relationships between various items in the system. The Relations tab in the ref`Details View <request-details-view>` of a Request serves this purpose.
The Relations tab gives you an option to create relationships between a Request and other Requests, Problems, Changes, Knowledge Articles/FAQs, and Assets.
You can view the present connections of the Request by using the item heads in Relation For section. You view the connections as a list.
You can create a new Request, Problem, Change or Asset and link it to the Request using the Create and Relate option.
The Add Relation option lets you add one or more relationships with existing Requests, Problems, Changes and Assets.
Clicking on Add Relation shows you a popup menu where you have to select either Request, Problem, Change or Asset.
A dialog box opens with a search box (it supports Advanced Search features)
Search for the right entry and click Link to add a relationship between your selection/selections and the Request.
1.2.5.8. Request Information¶
Requests created from the Service Catalog have additional information. The additional information is captured using a custom form; the field values are viewable under the Request Information tab in the Request Details View.
Related Topics
Understand the workflow behind creating Requests from the Service Catalog (Learn).
Understand how Service Categories and Templates are created.
Understand how a Service Item is created from a Template (Learn).
1.2.5.9. Time Log¶
Once a Technician gets assigned to a Request, he along with other Technicians can log their time spent working on the Request in the Time Log section of the Request.
1.2.5.9.1. Adding a Time Log¶
Go to the Details View of the Request.
Scroll down to the Time Log tab next to Approvals and click it.
Click on Add to add a new log.
Enter a Start Date Time (e.g., Mon, Dec 11, 2017, 5:12 PM), an End Date Time (e.g., Mon, Dec 11, 2017, 10:10 PM) and a description, and hit Add to save your log.
1.2.5.9.2. How to Edit/Delete Time Log:¶
Go to the Details View of the Request.
Scroll down to the Time Log tab. Click on the tab, and you see the time logs as a list.
Perform edits using the Edit Icon adjacent to a log. Alternatively, you can delete them using the Delete Icon.
1.2.5.10. Custom Fields¶
Custom fields are additional fields that appear on the Create a Request form (both Technician and Customer Portal) and the Details View of Requests. You can create such fields from the Admin section.
A field can be made compulsory in a particular status. For example, we created a field called employee ID and made it compulsory for the status Open; so anyone changing Status from Open to any other has to make sure the Employee ID is not empty.
Inputted values in the Custom field is shown in the Details View of a Request under Custom Fields tab.
1.2.5.11. Asking for Approval¶
This is an option a Technician assigned to a Request can utilize to seek approvals from others before resolving or closing a Request. The Approval process is a mechanism for control that ensures Technicians don’t commit unauthorized actions.
Custom rules, set by someone with Admin rights, decide whether taking Approval is necessary or not before resolving or closing a Request.
1.2.5.11.1. Initiating an Approval¶
Note
You need to be the assigned Technician in order to start the Approval process.
Go to the Details View of a Request.
Click on Ask for Approval from the Action Menu. This will send the approving person an email. The emails contains an approval link. Approving person can click on the link to go to the request and approve it.
1.2.5.11.2. Different States in an Approval Process¶
Approval Pending:
Approval Rejected:
Approval Pre-Approved:
Approval Approved:
1.2.5.11.3. Managing Approval¶
An assigned Technician can view all his Approvals under the Approvals tab. The Approvals tab shows two columns: the Approvals column which lists all the Approvals along with their approvers, and the Comments column that shows the message thread between Technicians and approvers. Any Technician with the necessary rights can access the Approvals tab of a Request.
An assigned Technician can create multiple Approvals (manually) with the same approvers or different ones; automatic Approval workflow can also create multiple Approvals. Between multiple Approvals, whether to go with unanimous or majority can be set from Admin (A Navigation Tab) >> Approval Workflow (Automation) >> Approval Settings, but the rights to do it lies with the Super Admin.
1.2.5.11.4. Approval Process¶
Note
An assigned Technician can initiate an Approval process for n number of times. At the start of each process, the Request will start from the Pending status.
An Approval can be initiated manually or automatically by an Approval Workflow. When the manual approval option is turned on, you get the following dialog box when you click on Ask for Approval.
When you create a manual approval, the system also checks for Approval workflows. Incase a workflow is triggered, both the manual approval and an automatic Approval are created. You can skip manual approval altogether using the Skip button.
When an Approval process is initiated, first the system changes the Request Approval status to Pending and then checks for available Approval Workflows. If there are no workflows and no manual approval, then the Request is pre-approved, and the Approval status is changed to Pre-Approved and Request status is changed to Pending on Technician. If there is a workflow or a manual approval, then based on its set conditions approver/approvers are auto-assigned/assigned for approval.
Note
Refer to Administration Manual to know more about Approval Workflows.
You can view all the approvers, their statuses and comments in the Approvals tab.
Once an Approval is set, the Approval status of the Request changes to Pending, and it stays there as long as the approver/approvers don’t express a decision.
An approver can see his Approvals in the My Approvals section of his account.
Clicking on My Approvals (
rmf-37
) opens the My Approval page where he can view his Approvals.Clicking on a Request Approval in My Approval opens a page with the title of the Approval as the header title. There he can perform the following actions:
Review the details and comments on the Request.
Start a comment thread which is visible to anyone having access to the comment section.
Reject or Approve the Approval.
The outcome of an Approval process is decided in two ways:
Unanimous: All of the Approvers have to approve else the Approval is rejected.
Majority: If the majority of Approvers agree then Approval is successful.
On success, the Approval moves to the Approved status and the Request status changes to Pending on Technician. On failure, the Approval moves to the Rejected status and Request status changes to Pending on Technician; the assigned Technician has to reinitiate the Approval process.
If a Technician has the right to ignore approvers (refer Administration Manual), then he can ignore non-responsive approvers and push the Approval towards the Approved stage. An ignored approver can see his status as Ignored in the Details View of the Request. An approver cannot see the Approvals where he/she was ignored in his/her MY Approvals section.
Ignoring all the approvers in an Approval changes the Approval status to Approved. A Technician can ignore or reinitiate an Approval using the Re-Approve option where a duplicate Approval is created, and the original Approval is ignored. You can Re-Approve an already Approved Approval; in that case, you can manually set the Request status to Pending in Approval.
During an Approval process, the following things cannot happen:
SLA cannot run during an Approval process. It stays paused still Approval is approved.
Location, Category, and Department cannot be modified.
Related Topics:
Understanding Approval Workflow
Creating an Approval Workflow
Allow Manual Approval
1.2.5.12. Managing Task¶
Sometimes resolving a Request becomes a collaboration between multiple Technicians; which is why the product allows delegation of tasks from the Details View of a Request.
Any Technician can assign Tasks to other Technicians related to any Request if he has manage Task rights. An assignee can see his Task/Tasks in his My Tasks section.
1.2.5.12.1. Adding a Task in a Request¶
Note
Managing tasks in a Request ticket requires the manage-task right for Requests.
Go to the Details View of a Request.
Click Add Task in the Task column under Work tab. The Add Task dialog box opens.
Give a suitable Subject that describes the Task. Select an assignee from the drop-down list in the Task Owner field.
Set the Priority, task type, time-frame (Start Date Time and End Date Time), and Description for the task and hit Create. You can also attached a file with the task.
1.2.5.12.2. Editing/Deleting Tasks¶
Go to the Request’s Task Column.
You can see all created Tasks. You can edit a Task using the Edit Icon and delete a Task using the Delete Icon. Perform the action you want.
1.2.5.12.3. Opening Task Details Pane¶
Go to the Request’s Task Column.
Click on the Task Details button which opens a pane where you can view the following:
Task Details
Comments
Time Log
Notify Settings
Audit Trail
1.2.5.12.4. Closing a Task¶
The assignee of the Task can directly go to the Details View by clicking on the Task title on his Dashboard.
Scroll down to the Task Column. You can close a Task by clicking on Done or changing the Status to Closed. Anyone with the necessary rights can perform this operation.
1.2.5.13. Notifications¶
The scope of a Request is broad in terms of stakeholders involved; communication plays a crucial role to make sure everyone is aware of the progress happening with the resolution process. Here bulk Notification features come handy to communicate with all stakeholders effectively and efficiently.
1.2.5.13.1. Send Email Notification¶
Go to the Details View of a Request.
In the Details View, click on the Action Menu and select Send Notification from the pop meu.
Clicking on Send Notification opens a dialog box.
Now choose the audience who receives your notification. You can select individuals or groups, be it Requesters or Technicians, or both. You can add multiple emails using the Add Email (section-A in
rmf-49
) button.Request specific details are there in the Subject and Body. You can edit the Subject and Body if you want. Make all the changes and hit Send. Now you have successfully sent a Notification.
4. View the Notification: A Technician can view all his Notifications that he created under Notifications tab in the Details View. Click on a Notification to get more details.
1.2.5.13.2. Send SMS Notification¶
Go to the Details View of a Request.
In the Details View, click on the Action Menu and select Send SMS Notification from the pop meu.
A popup will open up.
Fill the details in the popup.
View Notification: A Technician can view all his Notifications that he created under SMS Notifications tab in the Details View. Click on a Notification to get more details.
1.2.5.13.3. System Defined Request Notifications¶
Motadata has 13 Notifications that are predefined and generated automatically. They can be turned on by an Admin. The Notifications are as follows:
Notify ticket agent when Approver rejects an Approval.
Notify ticket agent when Approver approves an Approval.
Notify Approver when Approval is created.
Notify Approvers and ticket agent when a new comment is added to the Approval.
Acknowledge Requester when Request is reported.
Notify Technician when a Task is assigned.
Notify Requester when a Request is closed.
Notify Requester when Request is resolved.
Notify Technicians when they are mentioned in the conversation for a Request.
Notify Requester when Technician attaches solution for a Request.
Notify Requester when Technician reply to Requester for a Request.
Notify Technicians in a Group when Request is assigned to that Group.
Notify Technicians when a Request is assigned.
Note
Only an Admin can modify the content of the above-predefined Notifications.
1.2.5.14. Watchers¶
In a Request, it is likely that multiple stakeholders want to keep a watch so that necessary actions are taken promptly. With the Watch feature, one can subscribe to a specific Request and receive notifications that go to the Requestor.
Watchers of a Request are the default contact people for Notifications. Their names are added by default whenever a technician creates a Notification.
1.2.5.14.1. Adding/Editing People as Watchers¶
Go to the Details View of a Request.
In the Details View, click on the Action Menu and select Add Watcher from the popup menu.
Add Watcher dialog box opens. You can add people individually using their email addresses, or you can add groups available under Technician and Requestor, or you can use both emails and groups.
Add your watchers and save your changes before exiting.
Later you can use the Add Watcher dialog box to add/remove Watchers.
1.2.5.14.2. How a Technician can add Himself as a Watcher:¶
A Technician can be a Watcher too with a single click.
Head to the Details View of a Request.
Click on Watch in the Action Menu next to Assignment options, and you become a Watcher.
Click Unwatch in the Action Menu to unwatch the Request.
1.2.5.15. Split¶
You can create a new request from an existing request using split feature. The split option copies all the basic details of the ticket and pre-fills it while creating a new ticket. Click on the three vertical dots on the top right corner and click on the ‘Split’ button.
A popup will open up. The popup has all the basic details pre-filled from the existing ticket.
1.2.5.16. Jira Integration¶
If you have Jira integrated with Motadata, then you can directly add a Request to Jira from the product.
To add a Request:
Go to the Details View of a Request that you want to add.
The Integrations tab appears in all Requests when you have Jira integrated. Go to the Integrations tab.
Click on Add to Jira. A new dialog box opens.
Set Project, Issue Type, and Priority. Subject and Description are fetched from the Request. Click Add to begin the import.
1.2.5.17. Closing a Request¶
Motadata gives you multitude of ways to close a Request which are as follows:
Note
Pending Approvals are ignored after closing a ticket.
1.2.5.17.1. Closing from List View:¶
Go to Request >> Request List View.
Click on the Status of a Request and change it to Closed. The Request is now marked as closed.
1.2.5.17.2. Closing from Details View:¶
Go to the Details View of a Request.
There you can change the Status to close. If the Request is assigned to someone, then you can use the Close this Request option for closure.
1.2.5.17.3. Closure Rules¶
An Admin might set rules that prevent you from closing a Request unless you fulfill certain set conditions. Such conditions can be grouped under three heads:
User interaction
Mandatory Fields
Required State
To know more about Closure Rules refer to the Administration Manual.