IRE Recommendations for Use With the Integration
We have put together a few of the most used recommendations—guidance we have compiled while working with our customers configuring the Flexera One connector. These recommendations are specific to the Flexera One integration but could be considered for other external data sources that populate the CMDB.
| 1. | Reconciliation rules if there is more than one datasource: If you have more than one data source feeding ServiceNow that utilizes IRE, reconciliation rules are going to be essential in almost every case. You will want to give Flexera the highest priority for the “Model_id” and “Model_number” field so it can normalize the CIs and relate them to their lifecycle information. What you choose to prioritize beyond those is largely up to your data sources and business needs. |
| 2. | Use IRE/ServiceNow configuration to get the desired behavior: The IRE needs to be the source of truth and not the properties of the integration. Always use the ServiceNow system properties over the integration properties. The “import properties” are intended to be a safety mechanism to prevent “accidental” data imports before configuration in ServiceNow is complete. They are not meant to replace ServiceNow platform properties. |
For example, if you only wanted Flexera to update existing records and not create new ones for a CI class, you would do that by checking the box “Insert Computers” in the App properties still and using “IRE Data Source Rules” to prevent the data source of “FlexeraOne” from create records in that class. This is how ServiceNow is intended to work and it's generally best to work WITH ServiceNow architecture instead of “against” it.
| 3. | Staleness Processes are Important to Keep the CMDB Tables Accurate and Relevant Over Time: A stale configuration item (CI) is a CI that has not been updated within a specific number of days (for example, 90 days). The Flexera One connector is designed to enhance the data quality within the CMDB, enhance the trust and reliability of the data within the CMDB. Without addressing stale data it can lead to inaccurate lifecycle states, incorrect decisions where the data is used, and ultimately cause erosion of trust in the CMDB |
Engage the stakeholders and data stewards to build a process on how to address stale records. There are a few ways this can be accomplished within ServiceNow, such as the Data Archive Manager and/or configuration of the Data Refresh rules within the IRE. Configure and utilize the CMDB Dashboard to monitor the health of the CMDB.
| 4. | Don’t neglect maintenance of the "Source" table: The “source” table (cmdb_ci_source) associates data sources and their unique ID for a record with a record in the CMDB. All integrations that are adhering to best practice that integrate with CMDB should be writing to this table as not doing so will make key functionality such as “robust transform maps” fail. This, over time, can lead to two primary issues related to performance and incorrect coalescing of data, however. |
| • | Performance issues: The result of having multiple data sources writing relationships to CIs (hardware and software) in this table is that it can grow to a volume of records that slows the system when it needs to reference this table and impact performance of any data source that relies on it. |
Recommendation: Keep the “source” table as “lean” as possible. Utilize the scheduled job “CMDB Sys Object Source Cleanup” to clean up records that are no longer needed in that table and consider periodically cleaning up data sets for a specific data source completely to “refresh” their data. This is typically best done one data source at a time to allow that data source to re-establish relationships to prevent any data flip flopping before doing it for the next data source.
| • | Coalescing data issues: Sometimes the data present in this table can make resolving issues with identification impossible as ServiceNow will use the mappings in this table first and skip “identification rules” if it finds an existing relationship. While this is typically a “good” thing, sometimes it can be a problem. For example, if you were to make changes to identification rule to solve and coalesce issue that you’ve found, the relationships here could prevent the corrected rules from having the desired impact. |
Recommendation: Clean up the data related to the records impacted by any changes made to identification rules/coalesce values prior to testing those changes. This is not limited to changes on the ServiceNow side. If the data source itself has a change to a key value it may be necessary to clean up any records in the source table related to the CIs impacted as well.