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

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

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.

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.

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

No, it does not.

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.

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.

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.

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. 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. 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).

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

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.

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

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).

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).

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