This post is part two of a three-part series on how to leverage the Now Platform to easily solve otherwise tough reporting problems. This is a followup to the Performance Analytics and Reporting Office Hours from 2/12/2020. If you would like to hear me explain this, you can check out the recording and presentation here.
The Business Case
Ajay, a Problem Manager, is having some challenges building a dashboard to quickly identify any security-related PRB.
I need to quickly create a report of any active PRBs that are security-related. My support team does a great job labeling all the PRBs with [Security] in the short description, but I just can’t get my dashboard right.
Before we get started
This is part two of the series, so go back and read part one if you haven’t. You’ll also want to be sure to have had some training on the Now Platform. [That is also discussed in part 1, so go get the links there.]
Use Case Specifics
Let’s get to it. Our team is labeling security-related problems with “[Security]” in the short description.
This current process is:
- Easy to do – Good
- Easy to identify in a list view – Good
- Challenging to report on (can’t group or use interactive filters) - Bad
We want to be able to:
- Create interactive filters on our problems that are security-related or not
- Create reports on security vs. non-security problems
- Make some additional fields mandatory for security-related problems
Proposed Solution
To allow us to report more clearly on this information, we will add a field to the problem table that captures if this is a security issue or not.
Solution Walk Through
Create a new field
The key to making this reportable is creating a new field. Here we are creating a new field to show there is a security impact on this problem. On the first pass, this might make sense as a True/False field since it either is or it isn’t security-related. However, with a True/False field, we can never be sure if something is really “not security” related or if it wasn’t marked that way.
To better manage our data, we are using a Choice field instead of True/False. This will allow us to understand when something is or is not security-related or if we just haven’t determined yet.
In addition, we can use a standard UI Action to force this to be set at some point in the process. If appropriate, this new field could be included in an index on the problem table as well to improve performance for some reports.
Add Business Rule
While not required, to smooth the transition from using a tag in the short description to the field, we will add a simple Business Rule to set the flag if we find the string “[Sec”, set the Security Impact field to “Yes”.
This Business Rule is a pretty simple and will set the field but not unset the flag if you remove it. This could be enhanced further, but it meets our needs for now.
Run Fix Script
We are all set up to populate the data going forward, but we need to fix all the existing problem records. To do that, we’ll run this simple fix script that emulates the logic we have the Business Rule.
[This isn't the prettiest script, but it is functional.]
var getSecProblems = function ()
{
var prbs = new GlideRecord('problem');
prbs.addQuery('short_description', 'CONTAINS', '[Sec');
prbs.query();
return prbs;
};
var secPrb = getSecProblems();
secPrb.setWorkflow(false);
secPrb.autoSysFields(false);
secPrb.setEngines(false);
secPrb.setValue('u_security_impact', 'yes');
secPrb.updateMultiple();
var getNonSecProblems = function ()
{
var prbs = new GlideRecord('problem');
prbs.addQuery('short_description', 'DOES NOT CONTAIN', '[Sec');
prbs.query();
return prbs;
};
var nonSecPrb = getNonSecProblems();
nonSecPrb.setWorkflow(false);
nonSecPrb.autoSysFields(false);
nonSecPrb.setEngines(false);
nonSecPrb.setValue('u_security_impact', 'no');
nonSecPrb.updateMultiple();
Work is Better
Is Security Impact (in this example) is important to your organization, then adding a field is going to let you use this throughout the Platform. Adding fields should not be done for every one-off report you get asked for, but when there is a clear alignment to your business processes, it should always be an option.
By taking the string and converting to a field, we can now easily add Interactive Filters and Group By the new field without issue. While we didn’t look at it, we can also now use this field as a breakdown in Performance Analytics, in a UI Policy, in Business Rules, in Flow Designer... anywhere in the Platform.
Alternate Solution - Tags
An alternative solution for this use case is using tags. This is an improvement over using naming conventions but brings with it different reporting challenges. While the condition builder does support reporting on tags since tags support multiple levels of visibility, things that look the same may have different sys_ids are can be a challenge to keep straight.
Tags may be an excellent solution for temporary tracking with limited scope, but if we are looking for a robust solution, we should stick to a new field.
Other Use Cases
In this example, we looked at “Security” problems, but other similar use cases exist in the wild such as:
- “High Visibility” projects
- “Must Have” stories
- “VIP” incidents
Wrapping Up
The Now Platform is integral to Analytics. Do not restrict yourself to just Reporting or just Performance Analytics! Use the Now Platform to get the most out of your ServiceNow investment and optimize your workflow.
With a small amount of effort (this should have taken you less than 15 minutes to do), you now have greatly expanded your analytics capabilities with a solution you can use across the platform, not just in a one-off report.
Up Next
In the next installment of this series, we’ll cover reporting on lists. Check back next week to learn more about how to Conquer Challenging Reports by Leveraging the Now Platform.
In the meantime, please leave me some comments about the use cases you are solving with this technique.
