How to trigger "ci.change.unplanned" event to create an Unauthorized Change Request

[Trinh Huy]

Hi,
I'm researching about Unauthorized Change request, but i don't know how to trigger or use this in ServiceNow.
I have already read document of ServiceNow but i'm still not use it.
Does anyone have any experience in implementing this and willing to share these experiences?
Link document: https://docs.servicenow.com/en-US/bundle/sandiego-it-service-management/page/product/change-management/concept/unauthorized-change-request.html

[Moe9]

Hello,

Check out this post for more insight: https://www.servicenow.com/community/cmdb-forum/how-to-logged-change-ci-in-the-flapper-s-data-table-...

[AJ-TechTrek]

Hi @Trinh Huy ,

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/ref...

the OOTB implementation is a good start, but have lot of gaps. It checks only CI which are assigned to a Application Service.

Gaps:

1. It only works with Service Mapping.
2. New discovered (inserted) CIs are not detected as unauthorised Change, because naturally they are not attached to Application Services.
3. As Ed mentioned, it's only on class level. You can not decide which fields should be observed or not, e.g. change of free space of disks is not relevant. It seems there is a learning algorithm in the backend to remove such noises, but I guess this will take long time, to have this stable and only real unauthorised changes will be detected.
4. Also removed change relevant relationships will not be detected as unauthorised Change.  

What we did in the past is, that we built such logic on our own. So we created some Configuration class where you configure which classes and fields and which relationships are change relevant. In a Business Rule which runs on every update of CI by discovery, we checked if a matching class and field is changed the Change Requests will be checked. If there is no authorized Change, we flagged these CIs or created a unauthorised change (depended on Customer requirements). Also we ensured, that if everything is done on the right way, a CI of a change relevant class will never be created by discovery, because the CI sleeve was created by Change Request Workflow before discovery can detect it. So every new CIs in a change relevant Class without such a Change Request will be detected as unauthorised Change.

I hope these gaps will be closed in future, so that OOTB Unauthorised Change Detection needs no additional custom implementation.

https://docs.servicenow.com/bundle/washingtondc-it-service-management/page/product/change-management...

Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.

Thanks

AJ

Linkedin Profile:- https://www.linkedin.com/in/ajay-kumar-66a91385/

ServiceNow Community Rising Star 2024