CI Reconciliation rules for manual entry

[cloudyrobert]

I'm trying to use CI reconciliation rules to prevent users from manually updating a field that ServiceNow Discovery has set with a value. Mostly, I'm trying to understand how this works so that we can implement it for actual business cases, but take the example of IP. Let's say I want to prevent manual updates to a Windows Server's IP if the value has been set by Discovery. I've got this set up:

• Reconciliation Rules
• • Data source: ServiceNow
  • • Apply to all attributes: checked
    • Set to active w/ no filter condition
  • Data source: Manual Entry
  • • Attributes: Assignment group, Assigned to
    • Set to active w/ no filter condition
• Data Precedence Rules
• • Data source: ServiceNow
  • • Priority 100 & active
  • Data source: Manual Entry
  • • Priority 200 & active

It seems to do nothing. I can update the IP of a Windows Server manually with no problems. What am I missing?

[Jon G]

This is a bit frustrating for me as well.  I'm going through the process to move our CMDB imports from direct imports over to the Identification and Reconciliation engine

Half the point of this is to make certain data sources authoritative - in exactly the same way you are.  If our monitoring platform says that a Server has an IP address of X, then that should be authoritative.  I don't want users changing the IP address there, I want them to go fix the monitoring system if it is somehow wrong.

From everything I've found, I tend to agree that the only way to specify a data source is to pass it through the scriptable API, and manual updates do not trigger the IRE.

I'm curious if you've found any way to make this work the way we both seem to have expected?

[Chris Hagy]

I wonder if a Before Business rule could block the direct edit by resetting the value to previous[field] for interactive edits but redirect the submission through the IRE instead to allow you to take advantage of that feature. otherwise, I might lock down the ability to edit those you would want 'manually managed' and redirect the edits through a catalog item or maybe a service portal page to post them through the IRE instead of making the updates directly.

[cloudyrobert]

Unfortunately, I have not. I haven't investigated much, though. ChrisHagy's ideas sound like they might work, but I hate to have to go to that kind of length with code to do something that seems like it should be built into the platform.

[mbourla]

I've actually implemented what ChrisHagy has suggested.  A before business rule, which calls custom code that refers to the same tables that IRE uses for reconciliation & data source precedence definitions.  It also uses and maintains the table cmdb_datasource_last_update, which records the datasource that last updated each field on the CI. So it's compatible/consistent with IRE.

If the code run by the BR finds that the current source (which would normally be Manual Entry) has lower precedence (i.e. higher Order) than the datasource which last updated any given field, then it resets the field value back to what's on 'previous' and displays an info message to the user.

When I saw that 'Manual Entry' was one of the OOTB choices for discovery_source I naively assumed that IRE would handle precedence for manual input vs integrations/discovery, but sadly it doesn't.  I raised a HI case to check, and ServiceNow support confirmed that it doesn't.

I plan to extend what I've done slightly, to make any fields readonly on the CI form if the user can't update them due to datasource precedence.  Otherwise it's not a user-friendly experience to allow them to modify fields on the CI form, only to have certain field updates blocked when they save or submit.

I'm now wondering if I could or should have made things easier for myself by getting the BR to call the scripted IRE to do all the reconciliation and datasource precedence, instead of me replicating the equivalent functionality.  I could presumably have inspected the output payload from IRE to see which fields were blocked.  But anyway, what I've done works for us.

I do agree with relliott that this really should be in the base product.  There are other shortcomings or limitations I found with IRE, especially about its use from transform maps, which I've had to implement workarounds for.  Hopefully these things will get included into the base product at some stage.

Regards
Michael

[sabell2012]

Thanks Michael. Here is a HI KB that talks about the IRE shortcomings with SCCM integration; confirming what you were saying about update sets. This is a major deal for our customer base.

https://hi.service-now.com/kb_view.do?sysparm_article=KB0748948

With this and ignoring manual entry there are two major flaws present with the CMDB and IRE.

Thanks, your info was very useful for me, as we were running to the same thing with a client.

My team has also been running into anomalous behavior with Discovery (ServiceNow) and Service Mapping replacing each other even with IRE and precedence records present. This has happened for both New York and Orlando.

Currently I will be advising our clients to avoid the IRE for now, unfortunately. 😞

Thanks @doug.schulze for what you found as well.

Steven Bell