Problem Form
Edit Details tab.
All the information related to the Problem is present in this tab. A user can view/edit the fields and update the Problem.
| Fields | Description |
|---|---|
| Assigned To | User who works on the problem. |
| Category | Type of issue. |
| Closure Category | A category needs to be selected to resolve the problem. |
| Closure Notes | The notes will be added once the problem is resolved. |
| Configuration Item | Affected CI, if applicable. |
| Created On | Capture the date and time of problem registration. |
| Change | Capture the change request number. |
| Description | Detailed explanation on the problem. |
| Problem Statement | Brief description of the incident. |
| Impact | Impact is a measure of the effect. |
| Known Error | A Known Error is a problem that has a documented root cause and a Workaround. |
| Method of Notification | Communication method used by the user to create incidents |
| Major Problem | Indicates Major Problem |
| Priority | Priority is based on impact and urgency. The Priority Matrix is configurable and can be accessed from the Administration section of the application. Administration > Priority Matrix
|
| Reported By | User who contacted you with an issue |
| Status | Status of the Problem. Out of box choices are:
|
| Service | Indicates the services that are related to the problem. |
| Sub-Category | On Selecting Category, Select the Subcategory, if applicable. |
| Support Group | Group who will work on the problem. |
| Urgency | Urgency is a measure of how long the resolution can be delayed. |
Problem Task
A problem task is the smallest unit of work that you should perform to complete a problem. Divide a problem into multiple problem, which you can easily assign to different assignment groups or users. Within the General Tab, the Problem Task Section is located.
When creating a Problem task click on the “+ New Problem Task” Button and a New Problem Task Form is displayed.
Fill all the mandatory fields and click on the save button. Once saved it appears as Problem Task Records. Each record’s life cycle appears in the list, Email and other such life cycle triggered events are recorded in the Time Line Section of the Problem Task Form.
Problem Approval
View details regarding the approvals for the problem. The following details are captured:
- Approver Names: The names of the users who received the approval requests.
- Approvers’ Comments: Captures the approvers’ comments while responding to the request.
- Status: Captures whether the approver rejected or approved the request
- Module: Capture the problem number.
- Id: Capture the problem approval unique identifier number.
Timeline
The Timeline maintains a historical record referencing when a ticket is updated, or if any notes are added. Also, one can add attachments to the notes.
Analysis Information
Work Around:
A workaround can be put forth to fully resolve an issue to or to provide a temporary fix. A problem manager describes the workaround and can publish it to the attached incident.
Click On Publish Work Around Button on top Ribbon. Then the workaround will be published, and the state will convert into Draft, and notification is sent to related incidents that a workaround is available. After clicking on the button popup will appear.
Cause Notes
A problem is a cause of one or more incidents. Create a problem to identify the root cause of the incidents and try to prevent them from happening again.
Resolution Information Tab
Within the resolution information there are some fields which need to be entered during the resolved state so it can be track by whom the problem has been resolved and when its resolved.
Resolved By
In this field we are captured by whom this problem has been resolved.
Resolved On
In this field we are capture when the problem has been resolved.
fix Notes
In fix notes Problem Manager can provide the solution to fix the problem.
Other Related Incidents Tab
Inside the Other Related Incident, you can either add the incident Directly to click on “Add Existing Incident” or you can create new incident to click on “+ Add New Incident Details.”
Upon clicking the “Add Existing incident” button, all existing incident number are now visible, select one or more incidents to associate to the record.
Upon clicking the “+ New Incident Details” button, a New Incident form is presented, and all mandatory fields require data. After saving the incident is listed and presented in the related incidents records list.
Service Level Agreement (SLA).
A service-level agreement (SLA) is a commitment between a service provider and a client. Fundamental aspects of the service are quality, availability and responsibilities that are agreed upon between the service provider and the service user. You can create one or more Service Level Agreement (SLA) definitions and use them to create an SLA record. The SLA record provides a method to establish an SLA that are meaningful for your organization's requirements.
Create an SLA Master Record
Navigate to SLA Master section. Administration > SLA Master.
- Click New. The SLA Master form is displayed.
- On the form, fill in the fields.
SLA Master Section.
SLA Master Form.
| Fields | Description |
|---|---|
| SLA Name | Name that identifies the SLA |
| SLA Type | Select the type: Response or Resolution |
| SLA Duration | Specify the length of time in hours |
| Exclude Weekends and Holidays | Whether to include or exclude holidays. Specify Yes or No |
| Retroactive | Specify the SLA Start time: If Retroactive is “Yes” then |
| Send Notification after 25% of Time | Specify to send the Notification at 25% of SLA Duration: Yes or No |
| Send Notification after 50% of Time | Specify to send the Notification at 50% of SLA Duration: Yes or No |
| Send Notification after 75% of Time | Specify to send the Notification at 75% of SLA Duration: Yes or No |
| Time Zone | Specify the Time Zone |
Add a Company Holiday Record
Navigate to Holiday List Table. Foundation Data > Holiday List.
- Click New. The Company Holiday form is displayed.
- On the form, fill in the fields.
Holiday List Section.
- Based on the user Time Zone the holiday will be added in the SLA.
Company Holiday Form
Create an SLA Problem Configurations Record.
The table defines automatic assignment based upon an Incident’s priority, subcategory, and category values.
Navigate to SLA Configurations Tables. Administration > Incident SLA’s.
- Click New. The SLA Configurations form is displayed.
SLA Configuration Section
- On the form, fill in the fields.
SLA Configuration Section
| Fields | Description |
|---|---|
| SLA Name | Specify the SLA name that links to “SLA Master” table associated with the same name |
| Priority | Specify the Priority |
| Category | Specify the Category |
| Subcategory | Specify the Subcategory |
| Module | Specify the name of table |
SLA Process Example:
This example demonstrates how an SLA can be associated to a Problem:
Navigate to Problem Details section.
Problem Form
- Fill Category, Sub-Category, and Priority.
- Save the form.
SLA Task
SLA Notifications
Sending Reminder for SLA Breached
When a new Problem is created then the system matches the appropriate impact and urgency SLA, and it is then added into the SLA Task entity. Here is an example of the SLA Task entity containing entries.
Then from left navigation go to Administration > SLA Master.
SLA Master Section
Open that SLA Master Section from Left Navigation and see all the records of it.
SLA Master Records
Then compare the SLA Name and Type that we get in SLA Task entity and compare these two field with SLA Master Table entity.
Where these two fields are equal fetching that record from SLA Master Table and these records look like this:
Then checking the Field Value Sent Notification after 25% is Yes or No, if it is Yes then calculating the total Time Difference between Sla Start on and Breach Time field.
And after that we have total time for that SLA and after that calculate the 25% of that total time and after 25% time is completed then again check for SLA State in SLA Task.
If the state is still in progress, then go to that Problem from the left navigation and check for currently assigned support group or assigned to person.
And send Reminder Email to that Currently Assigned Person. if there is no Assigned Person then check for Currently Assigned Support Group And send Reminder Email to that Currently Assigned Support Group like this:
if there is no Support group and Currently Assigned Person then Send Reminder Email to Help Desk.
If the state is Cancelled or complete showing in the following image then the Notification will not send.
Then Email notification is send based on the state of the SLA Task and Reminder status should be yes
After sending 25% reminder Email again check for SLA State.
if it is still in progress then same process is followed for 50% and 75% Reminder Emails and for sending Breached SLA Reminder Email aging check for SLA State if it is still in IN Progress then send email notification.
- Other Related Change Tab
Inside the Other Related Change, you can either add the Change Directly to click on “Add Existing Change Records” or you can create new Change to click on “+ Add New Change Request”.
Upon clicking the Add Existing Change Records all existing Change numbers will be visible, and you can choose and click on the add button so selected Change will add.
Upon clicking the “+ New Change Request” Button, a New Change Request form opens, and all mandatory fields require data. After saving the Change a list is presented in the related Changes list.
Configuration Item Tab
The Other Related CI tab, enable Configuration Items to be added when clicking on “Add Existing Configuration Items.”
When clicking on “Add Existing Configuration Item” button, all existing Configuration Items are visible for selection. To link a Configuration Item, click on the “Add” button.
Audit History tab
Any changes/updates made to the Problem will be captured in the audit history tab. The person who made the changes will be captured along with the time and the updated fields.
Audit History is where the system stores historical information for all records. These records are intended to be kept forever so that administrators can always track the history of audited records. As the number of auditing records grows over time, it becomes more inefficient to directly query the Audit table for historical information.
