Event rule binding duplicate CIs

Terry Duong
Kilo Contributor

Hi All,

Sorry if the question is obvious, I'm still learning about service now - event management.

On our instance, we have 2 CIs with exact same name (one is capital, one is lowercase) but one is Retired. I'm trying to bind event to the active CI not the Retired CI but couldn't get it to work. I tried the below:

- Created event rule with Additional Information - ${u_active} with value is always true.

- Binding section set to Override default binding, binding type: CI field matching, CI type: Configuration Item.

I thought when binding SN will find 2 CIs and then use the u_active field to pick the one with value = true.

but SN can only find one CI as per below log:

Binding alert CI process flow:
Node will be resolved to CI id: 6d1323d44fa36600f9... : found by node name
Event CI type is cmdbi_ci
Checking for matching with processes that are running on the node
No matching CI found
No related CI found for binding, alert CI will be bound to node (id): 6d1323d44fa36600f9...
Bind to 6d1323d44fa36600f9...

I'm not sure if I'm on the right direction. If not could someone please point me to where I need to look into?

Thank you in advance,

Regards,

Terry

1 ACCEPTED SOLUTION

vNick
ServiceNow Employee
ServiceNow Employee

This can be done a couple ways (more actually).

First, what kind of binding are you applying?  CI Identification or CI Field Matching.  If CI Identification, then consider adding an identification inclusion rule that does not lookup "Retired" CIs.

 

If doing Field Matching, then add a manual attribute with the same name as the CI attribute you're setting as retired (operational_status or installed_status I assume), and set this to the value you want to match (operational, installed, etc)

View solution in original post

5 REPLIES 5

vNick
ServiceNow Employee
ServiceNow Employee

This can be done a couple ways (more actually).

First, what kind of binding are you applying?  CI Identification or CI Field Matching.  If CI Identification, then consider adding an identification inclusion rule that does not lookup "Retired" CIs.

 

If doing Field Matching, then add a manual attribute with the same name as the CI attribute you're setting as retired (operational_status or installed_status I assume), and set this to the value you want to match (operational, installed, etc)

vNick
ServiceNow Employee
ServiceNow Employee

Link to creating identification inclusion rules

https://docs.servicenow.com/bundle/kingston-servicenow-platform/page/product/configuration-management/task/create-id-inclusion-rule.html 

Thanks Nick,

I tried set up an inclusion rule before, not sure if I did it right but it didn't work for me.

Applies toInclusion condition
cmdb_ciinstall_status=1^operational_status=1^u_active=true^EQ

Once an inclusion rule created would I need to override the default identification rule on the even rule?

Maybe I should wait a bit before sending events over for the instance to propagate.

I'll test it again and let you know.

Thanks again for your help.

vNick
ServiceNow Employee
ServiceNow Employee

Hi Terry - no, those should take effect, but only if the event rule has the binding section set to use "CI Identification" and not "CI field matching".  Are all 3 of those attributes controlled?  I would only define the ones that are actually set as these will apply to ALL CIs when searching for a matching CI.

Is the example CI you are looking at something in the Hardware hierarchy where the "Node" value is set to something that would be an IP address or Name of the CI?