Creating a report on the Change Request table that pulls the Incident or Problem used to create it?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-01-2016 03:20 PM
I've got a customer requirement to show that Changes coming up for a CAB meeting are "authorized". I'd like to create this agenda using ServiceNow reporting rather than hack something up in Excel. There are lots of things that go in to "authorized", but the issue I'm having is this.
An authorized change is a change that has
(a bunch of conditions that are easy to check) OR the Change was created from an Incident, Problem, or RITM
I can easily check Change Request.RITM or Change Request.Parent. To my shock, there is no way to identify a parent Incident or a parent Problem. When you "Create Change" from an Incident or Problem, it does not establish a Parent-Child relationship or come up in any reference field on the Change Request table.
Is there any way to report on the Change table and pull the corresponding Incident or Problem from which the Change Record was created?
Thanks,
Rick R
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-01-2016 03:43 PM
How do you create a change from an incident? If in a UI action, we added a "recategorized" field on the change form and updated it using change.u_recategorized = current.sys_id; (from the incident table). Once you have that, it is easy to report on it.
Harel
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-02-2016 03:31 AM
Thanks for the response. Yes, modifying the UI action and dropping the original INC or PRB ticket number into either a reference field or even a plain text field would fix the issue. But I probably should have mentioned the constraint: we're in a multi-domain instance of SN and right now we're being asked to get stuff done without making any changes that would affect others running on the same instance. So right now adding a field or modifying the UI action is not the preferred solution.
I was kinda hoping that the UI action was already dropping the original INC or PRB into a field somewhere that we could read with reporting. We've got an "Incidents" related list that gets populated with the original INC number, but can't find any way to access that related list in reporting.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-02-2016 04:30 AM
How about creating a database view - use the primary table and the related lists table (incident) and then report on that view.
Also, have a look here: Reporting | How to Access Fields on Extended Tables
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-11-2016 09:20 AM
Thanks for that. Yes, a joined view for reporting is the solution that our devs are now working. I won't consider it solved until I actually see it work 🙂