NOTE: MY POSTINGS REFLECT MY OWN VIEWS AND DO NOT NECESSARILY REPRESENT THE VIEWS OF MY EMPLOYER, ACCENTURE.
DIFFICULTY LEVEL: INTERMEDIATE
Assumes basic knowledge and/or familiarity of ITIL, CMDB, and Business Services in ServiceNow.
____________________________________________________________________________
In my last article I showed how you can roll up Affected CIs to the Business Service form. These were associated through the Business Service Incidents (if any). This was done using a System Definition Relationship record.
This same type of issue exists for the Problem records as well. There is no OOB mechanism that exists where all of the Affected CIs from the associated Incidents can be displayed on the Problem form. In this article I will be showing how a mechanism can be created to provide this desired functionality.
The primary component we will be using to create this roll-up and association is a System Definition Relationship record.
Requirements/Design
1. Add the existing Affected CIs related list to the Incident form (we did this in the previous article, but I am repeating it here for those who don't care about Business Services! If you have done Lab 1.1 previously you can simply skip to Lab 1.2).
2. Create a mechanism to roll up a Problem's associated Incident's Affected CIs and display them as a related list on the Problem form.
3. Add the new related list to the Problem form.
Lab 1.1: Adding the Affected CIs Related List to the Incident Form
OOB you will find that there is no related list shown of all CIs affected by an incident; even though there is minimum of one if the Affected CI field is filled in. BTW, I consider this to be a bit of an oversight. This tab really should be already added to the form.
1. Navigate to Incidents -> Open. The open incident list view will be displayed.
2. Open one of the listed Incidents. The incident form will be displayed. Scroll to the bottom of the form and note that the Affected CI related list is not present.
At this point you might want to fill in the Affected CI field of this particular Incident (so that you have the minimum set of data to be displayed in the Affected CIs related list).
3. Right-click on the form header to bring up the context menu and go to Configure -> Related Lists. The Related Links choice form will be displayed.
4. Find Affected CIs in the Available list and move it to the Selected list (left-side).
5. Click on the save button. The Incident form will be redisplayed.
6. Navigate to the bottom of the form again. You will note that the Affected CIs related list is now displayed.
That polishes off our first requirement. Now to start on the next requirement by creating the Relationship!
Lab 1.2: Creating a Relationship Between Problem and Affected CIs
Now we need to create a Relationship record that will allow us to display a related list of our Affected CIs on the Problem form.
1. Navigate to System Definition -> Relationships. The Relationships List View will be displayed.
2. Click on the New button. The New Relationship form will be displayed.
3. Fill out the form with the following:
a. Name: Problem to Affected CIs
b. Applies to Table: Problem [problem]
c. Queries from Table: CIs Affected [task_ci]
d. Query with:
(function refineQuery(current, parent) {
var incidentList = _retrieveincidentList();
current.addQuery('task', 'IN', incidentList);
})(current, parent);
// Pull in all incidents related to a problem
function _retrieveincidentList() {
var incidentList = [];
var incidentRecords = new GlideRecord('incident');
incidentRecords.addQuery('problem_id', parent.sys_id);
incidentRecords.query();
while (incidentRecords.next()) {
incidentList.push(incidentRecords.getValue('sys_id'));
}
incidentList = new ArrayUtil().unique(incidentList);
return incidentList;
}
Note: The purpose of this code is to allow for a specific refinement of what actually gets displayed in the related list view. The beauty of the Relationship record is that it allows the developer to do a coded relationship and then specify which records will actually be displayed. The displayed records must be matchable to a value inside of the Queries From Table. I highly encourage you to investigate all that this mechanism is capable of!
e. Click the Submit button to save your work.
That completes requirement 2. This establishes a Related List association between the Affected CIs and Problem.
The final step will be to add our new Related List to the Problem form.
Lab 1.3: Adding the Related List to the Problem Form
1. Navigate to Problem -> Open, and open up any Problem that appears on the list view.
2. Right-Click on the Problem form to display the context menu, and choose Configure -> Related Lists. This will display the Related Lists form.
3. Scroll down on the Available (left) side of the slush-bucket control, and find Problem to Affected CIs. Move this to the Selected (right) side.
4. Click the Save button to save the form. The Problem form will be redisplayed.
5. Scroll to the bottom of the form to verify that the new Problem to Affected CIs related list is displayed.
Steps for testing:
1. Navigate to Incidents -> Open, and choose a couple of incidents to work with. Edit each incident and add a couple of Affected CIs to the the List View at the bottom of the form (use the Edit button). Take note of the Incident numbers. One of these could be that first incident you were working with back in lab 1.1.
2. Navigate to Problems -> Open, and choose a single Problem to work with. Edit the problem, and in the Incidents Related List add the two Incidents to the Problem (use the Edit button).
3. Right-Click on the Problem form to display the context menu and choose Reload Form.
4. Scroll to the bottom of the form and note the Problem to Affected CIs related list. You should now see it populated with all Affected CIs that have been associated to the Incidents. You may see duplicates. If so, note that they are due to the same CI associated to two different Incident records.
Here were my results:
Note: As an Admin I modified the List View to only show the Configuration Items, and their respective task numbers (Incident inherits from Task).
And that finishes up requirement number 3 and our unit test. It's ready for QA to take over now! Ship it!
Again, in this article, it was my intention to show the power and usefulness of the System Definition Relationship record. Cool, huh?!
Steven Bell
For a list of all of my articles: Community Code Snippets: Articles List to Date
Please Share, Like, Bookmark, Mark Helpful, or Comment this blog if you've found it helpful or insightful.
Also, if you are not already, I would like to encourage you to become a member of our blog!
