How to logged change CI in the flapper’s data table and check to raise Unauthorized change requests for unplanned change CI

[Hoang Duong]

 Set up ServiceNow job to collect log and create Unauthorized change requests for unplanned change CI

In the serviceNow's document there is a guide to create Unauthorized change requests for unplanned change CI but I don't understand it very well, is there a specific guide on how to do it like in the document?
1. logged in the flapper's data table
 2. runs a nightly job and executes various algorithms on the data that is collected to identify patterns that point to false positives.
3. determine whether all the new values are false
4. change to the CI that was detected is flagged as unauthorized and a ci.change.unplanned event is raised.

Does anyone have any experience in implementing this and willing to share these experiences or document to implement?

ServiceNow Document link:

https://docs.servicenow.com/en-US/bundle/sandiego-it-service-management/page/product/change-management/concept/unauthorized-change-request.html

[Sean Walters]

Hi Hoang, 

You can enable the event through this page.

Specifically you would want to turn this property on:

Enable event processing

Enable the property to create unauthorized change events when an unplanned CI change (ci.change.unplanned) event is triggered. Default value: False

Navigate to Change > Administration > Unauthorized Change Properties to view and edit the properties. 

This link provides more information around the fields and what you can configure. 

https://docs.servicenow.com/bundle/sandiego-it-service-management/page/product/change-management/reference/unauth-change-properties.html

Hope that helps.

[Hoang Duong]

Thank you for your answer

I have successfully tested creating Unauthorized Change Request by following the steps below

1. setting Unauthorized Change Properties
2. Create business rule to call event ci.change.unplanned and setting data to create Unauthorized Change Request for all change CI

It is not optimal way. I want to ask if there is a way as written in the document

1. Collect Change CI data to flapper table
2. Daily job to check on logged data, check that change CI is associated with a service changes or not, if not create an Unauthorized Change Request for change CI

Thank you.

[Sean Walters]

Hi Hoang, 

I believe that what you have requested for as optimal is part of the process for ServiceNow. 

1. The learning pattern identifies the false positives as follows:

When a CI property associated with a service changes, the new value (CI and field pair) is logged in the flapper’s data table.

2. An unauthorized change request is created when an unplanned CI change activity occurs, and the system triggers the following checks:

• The system checks to see if the CI is part of the allowed CI classes. If it is allowed, then the system checks to see if this specific CI has been flagged previously.
• If it was flagged and the previously created unauthorized change was within the notification ignore period, then no further action is taken.
• If not, then further checks are made to see whether this CI is associated to a change request that matches the condition stated in the properties.
• If not, then the change to the CI that was detected is flagged as unauthorized and a ci.change.unplanned event is raised.
• On receipt of the ci.change.unplanned event, the script checks to see if the Enable event processing field is true. If it is true, then an unauthorized change request is created. By default, this property is false.

So I think for you to achieve you optimal second case , you should be able to state a filtered query that compares the CI's to that a Service Change. 

Hope that helps. 

Please mark my answer correct and helpful if this resolves your issue.

[cynlink1]

Hi,

I am trying to get acquainted with unauthorized changes. Where can I learn more about the flapper's data table and the learning pattern? For instance, I would like to know the following:

-What is the name of the flapper's data table?

-How does the learning pattern identify false positives? Is it based on the change request being rejected?

-How many false positives must be identified for a CI before it learns not to create additional change requests when that CI property changes in the future?

Thanks!