Is is possible to have different IRE Rules for different Sources

[Chris McDevitt]

Experts,

Is possible to have Discovery Source A have a set of IRE Rules and Discovery Source B have its own set of IRE Rules?

There is a Tanium CMDB integration that sends its results to the IRE. The problem is that it is matching on Retired Assets, which that team does not want. Of course, we could prevent that, but the customer's ServiceNow Discovery team wants to match on Retired Assets so they do not create duplicates.  It does not appear as if we can fulfill both requirements. Thoughts?

[-O-]

Is the real goal here to not match, or to not update state?

[Chris McDevitt]

I would say the goal is to have Tanium data match on non-retired CIs, without affecting other tools that are importing data via the IRE. If the CI is non-retired then update it, otherwise create a new CI based on the Tanium data.

[-O-]

I wonder if a reconciliation rule, perhaps on hardware level, where one says that Source X can only update a CI if it is not retired would solve this?

[#5 · Accepted solution]

I am not aware of this being possible.  The IRE identification rules are defined so that it is source agnostic for identification.  It sounds like the business use case here is more along the lines of restricting updates.  Hypothetically even if you could do this via IRE identification rules, it would not find a match and create a duplicate CI which I am fairly certain is not the desired result.

To prevent updating a CI you could add a business rule to run before update that will filter to to retired assets and the discovery source of Tanium that would abort the transaction.