When the state of an incident changes ,log the changes in custom table for audit purpose .use Async

[somadileep840]

Hi Community ,

I had a requirement and need your help to achieve this .

When the state of an incident changes ,log the changes in custom table for auditing purpose . Use an Async business rule .

[JenniferRah]

Can you give more specifics into what part you need help with? You already said you are creating an Async business rule that is based on the condition of the state of the incident changing. I assume you have the custom table built?

Are you asking how to log the information into your custom table? Without knowing the fields of your table or what information you want to log, there's not much we can do to help with that.

[Mark Manders]

What is wrong with the OOB logging that is already there? Incident records are audited OOB, so the state changes are already logged.

Next to that, there are even metrics (OOB) that record every state change. Their purpose is to record the time a record (incident) has been on a certain state but could also be useful for auditing purposes.

Can you explain what the exact requirement is? Especially with ServiceNow's cost-model (custom tables cost money), it may be better to utilize existing functionality than to use a custom table for auditing.

In case it is absolutely necessary to ignore all OOB functionality and create your own (and that can only be the case after vigorously fighting this requirement), please share what you already have, because if it's not working, there must be something wrong with the script and without the script, you can get a thousands answers of what could be wrong, without providing you with a solution.

[Mark Manders]

Off topic: your question reads very weird. Where is this coming from? Who gave you this requirement. Because if this is really what you got

When the state of an incident changes ,log the changes in custom table for auditing purpose . Use an Async business rule .

---

then someone is outside of their role. A requirement is something you need because of some reason. It should NEVER contain the solution. The solution is what you provide and they should trust you to deliver the best possible solution, which in this case could even be a flow that just captures all changed fields to enable you to add more fields in the future, if needed. 

You are there to fulfill a requirement, not to be told how to do that. Ask the questions: why does this need to be logged at all? Why does this need to be registered in a custom table (see my previous answer)? Why do I need to use a BR? Why does it need to be async?  

Because all of this is in the 'requirement', there must be reasons and if you can't answer even one of these questions, you don't understand the requirement and it should be clarified. You are the guide of the people asking you to develop on their instance and you need to understand the 'why' behind what you are doing, or you can't do the job they are paying you to do.

And if it is a test in which they tell you how to do something to see how you manage it, that's also fine, but then you should have told us as well and also provide what you already did, because else you are just asking us to help you cheat and the people you work for will find out.