- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-24-2022 06:46 PM
In Event Management we are using the Create Incident OOB subflow to create Incidents. We have a strange issue where the actual CI in the alert was set to non-operational but somehow another CI was put into the Configuration Item field by this automation. That name of the CI that was used doesn't match the alert (SNMP). This is a strange CI that discovery is doing some strange updates too but before I try to figure out that mess, I need to know how I can find the script or whatever servicenow uses to pull in/find the CI in the alert/cmdb. From the Create Incident subflow I found that it uses AlertGR whatever that is. Where can I find where this is handled? From there I am hoping I can see why it picked this strange CI instead of the expected behavior which is to leave the field blank. Perhaps our implementation consultants did a customization to this that isn't documented. Thank you
Solved! Go to Solution.
- Labels:
-
Event Management
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-29-2022 01:13 AM
The event has a field "Node". This is used to find the CI for the alert.
In the event rule there is a step/tab "Binding" and there is the following text:
Default binding: Value of Node field will be used to try and match CI name, FQDN, IP or MAC Address for Host CIs, such as Computer, OS, Switch Router (any CI type extending cmdb_ci_hardware)
The value of the field node can also be changed in the event rule.
If the event description contains the hostname for example, it's possible to extract the hostname and use that as value for the field node.
Regards,
Michael
Michael
Please mark the suggestion as helpful/like, if you find it useful to you or others who wants to refer similar content.
Please mark the solution as correct, if the answer provided has resolved your query.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-25-2022 09:24 AM
It looks like the CI got related/found based on IP address. So the wrong CI had that same IP address. It looks like the CI gets connect to the event before the subflow for the Create Incident.
