• Include a source system value that represents “Last Logged On User” (or similar) of the asset so it can be transformed and mapped to the Assigned_To attribute (or other similar attribute) on a CMDB CI record as a foreign key reference to the master user table.

• Include a source system value that represents “Most Frequently Logged On User” (or similar) of the asset so it can be transformed and mapped to the Most_Frequent_User attribute (or other similar attribute) on a CMDB CI record as a foreign key reference to the master user table.

• Include a source system value that represents the “Business Owner” (or similar) of the asset so it can be transformed and mapped to the Owned_By attribute (or other similar attribute) on a CMDB CI record as a foreign key reference to the master user table.

• Modify the logic that determines an asset “Location” from the source system and how the value transformed and mapped into the Location attribute (or other similar attribute) on a CMDB CI record as a foreign key reference to the master Location table.

For example:

• For Server assets: Change the destination CMDB CI table to use a generic table/class (e.g. cmdb_ci_computer) instead of using an OS specialised class such as cmdb_ci_win_server or cmdb_ci_unix_server or cmdb_ci_linux_server etc.

• For SQL database records: Change the destination table where SQL database records are persisted.

• For Linux assets: Split Linux Severs and Desktops and persist to individual destination CI Classes.

• Hardware Model records: Change the destination table where Hardware Model records are persisted.

• Self-explanatory.

• Introduce new rules to read custom fields from the source system and transform/map into agreed fields/attributes on a CMDB CI record within the destination system.

• Modify the rules to determine physical vs virtual when the source system discovery/API technology does explicitly identify physical vs virtual server assets.

• Modify the rules to determine physical vs virtual using manufacturer and/or model attributes/values.

• Modify the values persisted for the following attributes on a record set-by-record set basis (e.g. modify values persisted for Apple Mac vs Windows PCs vs Printers vs Routers, etc etc etc)

  • The Category value (persisted against the CMDB CI record)

  • The Sub-Category value (persisted against the CMDB CI record)

• Modify the rules (value maps) that determine how a source system Status values is transformed and mapped into one/more destination system Status values.

• The following value maps can be overridden:

  • Hardware Status

  • Hardware Sub-Status

  • Install Status

  • Operational Status

• Modify the rules to suppress updating one/more of the Status values if the destination record Status value has been updated more recently than the source system value.

  For example:

  • The Install Status (in the destination system) is manually set to “In Stock” when a laptop/desktop is returned to “stock/store/spares”. The CI Synchronizer rules can be modified to only update the Install Status back to “installed” if the “Last Updated” date/time in the source system is later than the “Last Updated” date/time in the destination system.

For example:

• Entirely change the Discovery Source value from the standard used by CI Synchronizer.

• Dynamically include a prefix value in the Discovery Source value based on attributes of the source system records (e.g. if the source system discovery technology is being used in a MSP/multi-customer scenario the Discovery Source could be prefixed with a customer identify/reference so the MSP understands which customer the CIs relate to in the CMDB).

For example:

• Dynamically include a prefix value in the Correlation ID value based on attributes of the source system records (e.g. if the source system discovery technology is being used in a MSP/multi-customer scenario the Correlation ID could be prefixed with a customer identify/reference so the MSP understands which customer the CIs relate to in the CMDB).

For example:

• Transform/map Azure Tag values (that store business information about Azure resources) into CMDB fields/attributes such as Environment, Owner, Cost Center, and so on.

• Transform/map Custom Fields in solutions such as Lansweeper to achieve the same outcome as above.

• Create customer specific rules to automatically set the Service ID of an Application Service against the “entry point” CI in the CMDB and create the corresponding relationship between the “entry point” CI and the Application Service.

  For example:

  • Use a Service ID value stored in an Azure Tag (or similar)

  • Use a Service ID value stored in a source system Custom Field (or similar)

• If a customer has enabled the ServiceNow Field Normalisation Plug-In the default behaviour will be impacted as CI Synchronizer attempts to match reference data such as Manufacturers, Models (and other reference/master data).

• The CI Synchronizer default rules can be amended to match against the ServiceNow normalisation/alias tables rather than the native reference table.