Fundamentals of the LeanIX integration with ServiceNow (CMDB)
The LeanIX-ServiceNow Integration is a powerful way to enable transparent flow of data between the two systems. This documentation covers key information to help you understand the Integration more deeply:
- Communication with ServiceNow.
- The core concepts used to integrate.
- The default supported configuration and best practices.
Before enabling the LeanIX-ServiceNow integration, please make sure you or a colleague/consultant working with you has the fundamental knowledge about ServiceNow CMDB, CSDM, and the ability to do the following within your instance -
- Manage installation and configuration plugins from the ServiceNow store
- Manage users, tables and ACLs in the CMDB
Communication with ServiceNow
The communication between the LeanIX integration running on LeanIX servers and the ServiceNow system depends on the configuration specified in ServiceNow URL.
In case the ServiceNow URL is configured with an
https schema, the communication is done through TLS encryption. Furthermore, all client credentials are stored as part of the configuration encrypted using
Additionally, the Integration User created can utilize both
Basic Auth or
oAuth 2.0 for authentication between the two systems.
Communication method when using HTTPS Instance URL
The TLS version and cipher suites used for communication between LeanIX integration and ServiceNow depends on the negotiation to the ServiceNow HTTPS server. In general,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256is used for any HTTPS connection to ServiceNow.
The ServiceNow URL mentioned above and the other integration user details are configured in the Integration credentials tab.
|1||ServiceNow URL section to input url of the instance which is to be connected with the workspace. e.g. |
|2||Username section to input the username of the LeanIX Integration user created within the ServiceNow Instance|
|3||In case Short event buffering is activated, all changes in LeanIX and SN will be synchronized immediately. This setting is useful for testing or demo purposes, but it will increase the amount of CPU usage and network traffic and should be disabled for production workspaces.|
|4||Managing User dropdown allows to utilize a technical user on the LeanIX workspace to run the Integration. This is useful for auditing purposes.|
|5||Use Proxy User check-box is only needed to be activated if the ServiceNow Instance requires a single IP address that can call it as per whitelisting rules. The helptext box provides the IP address that is required to be whitelisted as well in such a use-case.|
When the sync between the LeanIX and the ServiceNow is in the running phase, it is not possible to stop or interrupt this process.
For synchronization purposes, every mapping between tables in both systems defines the following:
|1||LeanIX Fact Sheet Type|
|2||Name of the table in ServiceNow|
|3||Defined source of truth|
|4||Whether one should use the 'strict' mode, i.e. whether unsynchronized objects from the non-source table/Fact Sheet type should be deleted right away. This makes sure that both systems always have the same data. This means, that if you delete a Fact Sheet in LeanIX, without having set a 'strict' mode, the Fact Sheet would not be deleted on Service Now side|
|5||Whether there are any synchronization constraints, e.g. only synchronize applications with a specific lifecycle status or only synchronizing software product models which are actually installed on a server belonging to a managed business application|
Within each mapping type described above, it is possible to configure field level mapping between the two systems.
|1||Type of field mapping (Further explained, in the setup in LeanIX documentation)|
|2||Name of field in LeanIX (if applicable)|
|3||Name of field in ServiceNow (if applicable)|
|4||Whether the attribute is to be synced from the defined source of truth or the opposite of the defined source.|
|5||How values are being mapped (as is or explicit mapping of one value to another)|
LeanIX-ServiceNow Integration is compatible with CSDM 4.0 guidelines
As of the last update of this documentation, our suggested default configuration below is in alignment with CSDM 4.0. Please feel free to reach out to your CSM for any specific questions.
Before implementing the integration, it is recommended to review the current maturity level of the ServiceNow Instance to be connected. Maturity and availability of modules within the ServiceNow instance will implicate what configurations can be used and not used while connecting with LeanIX.
A decision table, with suggested configuration workflow is as follows -
|Maturity State||Modules Required||Flow|
|Ready to sync Applications, Business Capabilities, and their relationships to ServiceNow.||n/a||Default Mapping|
Note - The IT Component section of the flowchart does not apply.
|Ready to sync IT Components of category Hardware, Software and their relationships with Applications from ServiceNow.||Software Asset Management (SAM)|
Link between the Software Discovery Model and the Software Product Model record required through the
|(Same as above)|
Ready to sync IT Components of category Hardware, Software and their relationships with Applications from ServiceNow.
|Software Asset Management Professional (SAM Pro)|
Default Mapping (SAM Pro) - Recommended for large ServiceNow Instances.
The flow chart helps illustrate the relations between ServiceNow tables and data flow conditions when constraints are used within the configuration.
Default Mapping (SAM Pro)
Connecting IT Component Software in LeanIX with Software Discovery Model table in ServiceNow is recommended in cases where the Software Product Model table does not contain enough information or the ServiceNow Instance connected is too large to perform dynamic link matching as described in Figure 1.
Review record size
One way to ascertain if this case applies is to check if the total number records collectively within the
cmdb_sam_sw_discovery_modeltable are larger than 1 million records.
In such a case, for customers with ServiceNow SAM Pro, the table of
cmdb_sam_sw_discovery_model (Software Discovery Model) should be linked instead to IT Components Software.
However, in order to ensure only records relevant within LeanIX come through, it is mandatory to have a filter applied to only pull relevant Discovery Models. Example of such a filter to be applied on the Discovery Model table is as follows -
statusINmanually normalized,normalized,partially normalized^norm_versionISNOTEMPTY^norm_publisherISNOTEMPTY^norm_typeINlicensable,not licensable,unknown
The fields of
Main Category, and
Product Type within the Software Discovery Model table help in further rationalizing the list of records while setting the filter.
Review the number of records left with the filter applied
As the table can easily store hundreds and thousands of records, it is important to review the filter applied and the records that remain with it. A good estimate is to ensure that the records remaining in the table are less than <20k records.
Legacy Software Management Connection
If in case legacy software management module is in use instead of SAM/SAM Pro and Discovery Service, the Integration can be adapted instead to follow the following flow chart instead -
It is possible to sync records between custom tables, fields and also CMDB tables not part of the figures shown above. However, it is not possible to fully support all use-cases in all conditions and has to be reviewed on a case by case basis.
Updated about 2 months ago