CI Synchronizer (Professional Edition) provides a comprehensive solution for CMDB automation with out-of-the-box support for a large range of asset/record types and CI-to-CI relationships, a range of source and destination connectors, and rapid deployment.

CI Synchronizer (Enterprise Edition) offers everything in Professional Edition along with advanced customisation options, several additional features such as Application Service Mapping, Digital Certificate syncing, additional related lists and and support for larger and more complex data synchronisation requirements. Enterprise Edition also allows for bespoke configuration of CMDB data rules and support for additional Azure regions.

Many! Check out each source connector page for details of the supported assets and other records.

Yes. CI Synchronizer automatically creates a large number of relationships in the CMDB by analysing dependencies between the source data. This is a fully automated and dynamic feature and allows organisations to use ServiceNow’s depending mapping features. There are tremendous benefits to processes such as Change Management, Incident Management, Problem Management and more.

CI Sync only updates the ServiceNow CMDB_CI_* tables. However, ServiceNow’s OOTB business rules automatically sync data bi-directionally between the CMDB CI tables and the Asset (ALM) tables. Therefore, CI Synchronizer ultimately helps to deliver data into your ServiceNow CMDB and Asset tables.

No, it does not.

No, it does not. CI Synchronizer uses the ServiceNow REST APIs to insert/update CI records in ServiceNow.

No custom tables are required, unless you are synchronizing Digital Certificate data or CVE data from Lansweeper in which case Syncfish will discuss the options for persisting those record sets in a suitable table in ServiceNow.

No. CI Synchronizer uses its own correlation engine which handles many more record types than IRE (Identification and Reconciliation Engine). The CI Synchronizer correlation rules can be customised if needed (though this is rarely required as the correlation rules have been highly tuned).

No, it does not.

Yes. CI Synchronizer can detect which source records have changed since the previous synchronisation job and only sync the newly changed source data.

Throughput is affected by factors outside of the control of CI Synchronizer, however we see a typical throughput of between 200,000 and 400,000 records per hour (and even higher rates are possible).

Yes. CI Synchronizer has a highly customisable rules engine. Such changes are made by Syncfish.

No. CI Synchronizer has an extensible multi-source/multi-destination architecture. The most common destination used is ServiceNow and there are a variety of Source connectors (with Lansweeper On-Premise being the most popular).

Yes. Please use the “Organise a Demo” button or visit the Contact Us page to book a time to meet with one of the Syncfish team.

No. Each customer is provisioned with a dedicated CI Synchronizer instance.

Ultimately the customer decides, however Syncfish recommends hosting each customer instance physically close to the location of their ServiceNow instance (for best performance). It can be hosted in most/all Azure Regions globally (it is still hosted/managed/maintained by Syncfish, but the customer decides which geography it is physically located in).

No. The source asset data (read from the relevant source system by one of the CI Synchronizer connectors) is transited through your dedicated CI Synchronizer instance then deleted after it’s been processed into ServiceNow.

Yes. CI Synchronizer will correlate with existing CIs in your CMDB. Also, CI Synchronizer can use “split transform maps” which means different rules can be applied to insert vs update events.

Yes. The CI Synchronizer rules can be customised on a customer-by-customer basis to meet the unique needs of your customised CMDB design.

CI Sync uses the OOTB ServiceNow REST APIs which do not require an ITOM licence. If an organization starts using additional ServiceNow features that take advantage of the source data being sync’d into the CMDB, then naturally the organization needs to licence such features.