Issue Management workflow

rohitg
Giga Contributor

Hi,

This ask is with reference to our very known Critical GRC pillar, issue and Actions Management.

I believe this is one place which goes hand in hand with every module / app in the GRC space (anything goes wrong can trigger an issue and needs action plans to fix it). Now with regards to this, i am not completely sure how can i leverage ServiceNow Issue and Action management workflow providing there has to be multiple people playing some kind of role to execute / review / approve and finally close the issue.

Baseline functionality allows one person to literally do everything, starting from Identifying an Issue (Manually or System driven (control test failure / indicator failure). I wonder if someone has got any good examples where they may have configured issue management lifecycle where we have Issue Owner, Issue Approver etc.

Lastly, what is the difference between issue remediation vs. issue acceptance? How will it make any difference? Why can't we simply have Remediate / Accept / Reject kind of process?

Happy to hear your thoughts on the above and learn something from you guys.

Regards,

Rohit

8 REPLIES 8

SanjivMeher
Kilo Patron
Kilo Patron

ServiceNow out of box functionality only provides basic functionality, but you can make changes to it based on your requirement, without impacting the existing functionality.

 

For ex. In our case, when an issue is linked to Audit, we have customized the issue management to send the issue for Approval, when an extension is needed to the current due date. We also have added few additional fields such as VP etc to track the issue by VPs.

 

Issue Remediation is when owner can remediate the issue, they mark the response as remediate. Now if there are multiple teams involved, you should create Remediation tasks for each team, so that each team can work independently.

 

Issue Acceptance is when you don't have any option to fix it currently or in future. We provide user option to create an exception is such case. So if they want to accept the issue, they must created an exception.


Please mark this response as correct or helpful if it assisted you with your question.

I agree with @Sanjiv Meher - I frequently tell students in class that there is no "one right way" to process an issue.  We have found a variety of ways when talking to customers - so in the baseline, we provide the structure for issue management; but expect the customer to build it out to meet their requirements.

Hi Meher - thanks for your response. It was helpful.

What I manage to gather so far in the issue management space is, this is more of a green field where I can do whatever I feel like. Which is good but not sustainable, as the way ServiceNow product team are releasing new stuff every now and then, I don't want to be in a situation where I develop something which is fulfilling my current needs but wont be able to upscale with ServiceNow roadmap.

The main problem right now in Issue Management is, 1 person is able to complete the entire process. In which case why do I even have so many stages of the workflow? I am not sure if there are any Issue specific roles available?

Hope my ask is bit more clear now.

Regards,

Rohit

Issue is just to store the ownership of the issue, because it will be created due to a control failure or audit failure and an owner is responsible to get it fixed. If multiple teams are involved, the owner should create multiple Remediation tasks.

You can also utilize the assigned to and assignment group field in issue, if a group needs track the issue.

I know ServiceNow is doing lot of stuffs. But we are not sure, when those functionality will be available and if those would be useful for our customer. So I prefer adding some customization which will not impact the OOB functionality, like adding an additional fields wont impact the upgrade. Then later when the new functionality is launched, test it with your customization and do adjustments. 


Please mark this response as correct or helpful if it assisted you with your question.