Configuring Applications for the CMDB SyncPack

This section describes the how to configure and run the various PowerFlow applications contained in the "ServiceNow CMDB" SyncPack.

A PowerFlow application is a JSON object that includes all the information required for executing an integration on the PowerFlow platform. A PowerFlow application combines a set of steps that execute a workflow. You can configure the parameters in the application to customize the sync process.

While a PowerFlow application is running on the Applications page, you will see a dark green, horizontal line moving across the top of the page until the process completes.

Creating and Aligning a Configuration Object

A configuration object supplies the login credentials and other required information needed to execute the steps for an application in PowerFlow. The Configurations page () of the PowerFlow user interface lists all available configuration objects for that system.

You can create as many configuration objects as you need. A PowerFlow application can only use one configuration object at a time, but you can use (or "align") the same configuration object with multiple applications.

To use this SyncPack, you will need to create one or more configuration objects in the PowerFlow user interface and align that configuration object to the applications that let you sync data between SL1 and ServiceNow.

Depending on your SL1 and ServiceNow environments, you might be able to use the same configuration object with other ServiceNow SyncPacks.

When either multiple SL1 stacks or multiple ServiceNow systems are involved with PowerFlow, you should create an individual configuration object for each SL1 stack or ServiceNow system. Next, create an individual schedule for each configuration object. Each schedule should use a configuration object that is specific to that single SL1 stack or ServiceNow system. Creating copies of a PowerFlow application from a SyncPack for the purpose of distinguishing between domains is not supported, and will result in issues on upgrades.

Creating a Configuration Object

For this SyncPack, you can make a copy of the "ServiceNow SyncPack" configuration object, which is the sample configuration file that was installed with the "ServiceNow Base" SyncPack.

The "ServiceNow SyncPack" configuration object contains all of the required variables. Make a copy of the configuration object and update the variables from that object to match your SL1 and ServiceNow settings.

To create a configuration object based on the "ServiceNow SyncPack" configuration object:

In the PowerFlow user interface, go to the Configurations page ().
Click the Edit button for the "ServiceNow SyncPack" configuration object. The Configuration pane appears.

Click Toggle JSON Editor to show the JSON code. Click the button again to see the fields.

Click Copy as. The Create Configuration pane appears.

This step is required. Do not use the original configuration object to run PowerFlow applications.
Complete the following fields:

Friendly Name. Name of the configuration object that will display on the Configurations page.
Description. A brief description of the configuration object.
Author. User or organization that created the configuration object.
Version. Version of the configuration object.

In the Configuration Data field, include the required block of code to ensure that the applications aligned to this configuration object do not fail:

  {
    "encrypted": false,
    "name": "sl1_db_host",
    "value": "${config.sl1_host}"
  },

For example:

  {
    "encrypted": false,
    "name": "sl1_db_host",
    "value": "10.2.11.42"
  },

In the Configuration Data Values field, update the default variable definitions to match your PowerFlow configuration.

The region value is a user-defined variable that identifies your SL1 instance within ServiceNow.

To create a configuration variable in the JSON Editor, define the following keys:

encrypted. Specifies whether the value will appear in plain text or encrypted in this JSON file. If you set this to "true", when the value is uploaded, PowerFlow encrypts the value of the variable. The plain text value cannot be retrieved again by an end user. The encryption key is unique to each PowerFlow system. The value is followed by a comma.
name. Specifies the name of the configuration file, without the JSON suffix. This value appears in the user interface. The value is surrounded by double-quotes and followed by a comma.
value. Specifies the value to assign to the variable. The value is surrounded by double-quotes and followed by a comma.

Click Save. You can now align this configuration object with one or more applications.

Aligning a Configuration Object

Before you can run the applications in this SyncPack, you must first "align" a configuration object with the application you want to use.

To align a configuration object with an application:

From the Applications page of the PowerFlow user interface, open the relevant application and click Configure (). The Configurations pane for that application appears:
From the Configurations drop-down, select the configuration object you want to use.
Click Save to align that configuration with the application.
Repeat this process for every other application you want to use.

NOTE: The values for eventDetails and the other parameters that appear in the Configuration pane with a padlock icon () are populated by the configuration object.

Syncing Organizations

An Organization Sync uses the "Sync Organizations from SL1 to ServiceNow" application to sync organizations from SL1 with ServiceNow companies. In this context, sync means that if you update a company in ServiceNow, the Organization Sync process will update the SL1 organization with that information, and vice versa.

If your ServiceNow environment is domain-separated, where the data, processes, and administrative tasks have been organized into logical groupings called domains, then the first sync you should run on a new PowerFlow system is an Organization Sync. For more information, see For Domain-separated ServiceNow Environments Only.

If your ServiceNow configuration does not use domain separation, you do not need to run an Organization Sync as the first sync. However, if you want to filter by organization with any of the other syncs in this SyncPack, such as Device Sync, File System Sync, and Interface Sync, you will need to run the Organization Sync as documented in the steps below.

Starting with version 3.5.0 of this SyncPack, a new table and API were created to let multiple SL1 systems support duplicate SL1 organizations syncing to one ServiceNow company, particularly for a domain-separated company.

For Domain-separated ServiceNow Environments Only

Starting with version 3.5.0 of this SyncPack, the following fields are no longer being used on the Company table (core_company) in ServiceNow:

SL1 Monitored
SL1 Region
SL1 ID

The ScienceLogic-specific information was moved to an application-specific table (x_sclo_scilogic_organizations) to track which Organization goes with any specific Company.

Creating new records is currently only available with the x_sclo_scilogic.admin role.

Creating a Linking Record for Domain-separated ServiceNow Instances

Before running the "Sync Organizations from SL1 to ServiceNow" application for the first time in a domain-separated environment, you will need to create a linking record in ServiceNow. You should also create a linking record if you select ServiceNow as the "source of truth" on the Configuration page of the "Sync Organizations from SL1 to ServiceNow" application, even if your ServiceNow instance is not domain-separated.

The linking record lets you set up the following configurations:

Tracking the relationship of a single SL1 organization with a single ServiceNow company in multiple SL1 databases.
Matching multiple SL1 organizations to the same ServiceNow company.
Importing a ServiceNow company into SL1 as an SL1 organization.

ScienceLogic highly recommends that you try out this feature in test environment before pushing to production.

If you set up an Organization Sync with a version of this SyncPack earlier than version 3.5.0, you will need to create a linking record when you upgrade to version 3.5.0 or later. The linking record is only required when you upgrade if you use ServiceNow as the source of truth.

To create a linking record:

In ServiceNow, navigate to ScienceLogic > Supporting Imports > Organization Source.
Click New. A new record appears:
Complete the following required fields:

Region. Set this value to match the region value in the configuration object aligned with the "Sync Organizations from SL1 to ServiceNow" application in the PowerFlow user interface.
Company. You would only need to use this field if you either want SL1 to create the organization or you want to link a specific SL1 organization with a specific ServiceNow company. To do this, search for the name of the ServiceNow company you want to link to (or have SL1 create). Otherwise, you can leave this field blank.

Because this a document field, you must add the Company [core_company] table in the Table name field, and then click the magnifying class icon to locate a company from the Document field:
Monitored. Set to True (checked).

The following fields are not required, or they are required under specific conditions:
- ID. Use this field only if you want to link a specific SL1 organization with a specific ServiceNow company. To do this, locate the value for that organization in the ID column of the Organizations page (Registry > Accounts > Organizations) in SL1. Otherwise, you can leave this field blank.
- native key. This key is a unique identifier for an SL1 organization, from a specific SL1 database. Use the following format:
Repeat steps 2-4 to create a linking record for every instance where you want to track the relationship of a single organization with a single company in multiple SL1 databases.
Go to the following topic to run the "Sync Organizations from SL1 to ServiceNow" application. Make sure that the Source_of _Truth field on the Configuration pane is set correctly to ServiceNow.

For Case Integration ServiceNow Environments Only

Add the following roles to the Integration user so that user can interact with the "ScienceLogic SL1: Customer Service Management Integration" Application in ServiceNow.

x_sclo_case_mgmt.admin. Provides user rights to interact with the scoped application tables and modules in ServiceNow.
import_transformer. Provides user rights to manage import set transform maps, run transforms, and access responses.

If your ServiceNow environment is using the Case Integration module and you intend to use customer_account records, you will need to add additional rights to the Integration user. These rights allow the Integration user to read the table fields:

sn_customerservice.customer_data_viewer

You will need to add cross-scoped access for read-only to the customer_account table as well. ScienceLogic recommends that you use ServiceNow as the source of truth for Organizations (Companies). For more information, see Allowing Cross-Scoped Access in ServiceNow.

Configuring Organization Sync

Organization Sync uses the "Sync Organizations from SL1 to ServiceNow" application to pull organizations from SL1 and sync them with ServiceNow companies.

To sync SL1 organizations with ServiceNow companies:

In the PowerFlow user interface, go to the Applications page and select the "Sync Organizations from SL1 to ServiceNow" application. The application page for that application appears.
Click Configure (). The Configuration pane appears:

Complete the following fields, as needed:

Configuration. Select the configuration object with the relevant SL1 and ServiceNow credentials to align with this application. You cannot edit fields that are populated by the configuration object. Required.

The region field is populated by the configuration object you aligned with this application. The region value must match the value in the SL1 Region field in ServiceNow. If you need to update this value, you will need to define the region variable in the configuration object that is aligned with this application, or align a different configuration object that has the correct region value.
read_timeout. Specify the maximum amount of time in seconds that the application should wait for a response before timing out.
snow_chunk_size. Specify the number of organizations to include in each chunk sent to ServiceNow when you run this application.
verify_snow_ssl. Toggle on (blue) this option to enable verification of the SSL certification when you run this application.
Update_Name. This option addresses the situation where PowerFlow finds a match with an organization and a company, but the names do not match. This option updates a company or organization name based on your selection in the Source_of_Truth field, below. For example, if you selected ScienceLogic as the source of truth, PowerFlow uses the company name from ScienceLogic as the updated name. By default, this option is not selected.
Create_Missing. Select this option if you want PowerFlow to create a new organization or company if that record is missing, based on your selection in the Source_of_Truth field. By default, this option is not selected.

Starting with version 3.5.0 of this SyncPack, the Domain Separation parameter was removed from the Configuration pane. Domain separation is still supported, but this parameter no longer needs to be selected.

Starting with version 3.5.0 of this SyncPack, the Update_Name parameters was removed. You can remove the mapping to the name value if you do not want to map the name back to SL1.
Source_of_Truth. Select whether you want to use data from ServiceNow or ScienceLogic as the "source of truth" when this application encounters duplicate data or data collisions. In most situations, the source of truth would be the application where you initially configured and created the companies or organizations.

If you select ServiceNow, you must specify the values in the Monitored and Region fields in ServiceNow. Because these fields do not display by default on the Companies page in ServiceNow, navigate to the Companies page, click the Update Personalized List icon (), and add the Monitored and Region columns to that page.
If your ServiceNow configuration uses domain separation, you must select ServiceNow as the source of truth.
If you select ScienceLogic, you do not need to do anything else related to this field.

In the attribute_mappings section, you can edit or create a mapping for any other organization attributes, such as address and contact information, that you want to sync between SL1 (the first column) and ServiceNow (the second column). A set of organization attributes are already mapped by default.

You can use Jinja2 Templates in fields that are aligned with the "Source of Truth" you selected (the left column is for SL1, and the right column is for ServiceNow). For more information, see Using a Jinja2 Template.
To edit an existing organization attribute in the attribute_mappings section, click the attribute name and either select an attribute from the list or type a new name for the attribute. Press Enter after editing the attribute to make sure your changes are saved.

Use the Tab button to move down through the list of options in a drop-down list, press Shift+Tab to move up, and press Enter to select a highlighted option.
To create an organization attribute in the attribute_mappings section, click the Add Mapping button at the bottom of the section, type a name for the attribute in the first field, and select one or more ServiceNow attributes to which the SL1 attribute should sync in the maps to field. Press Enter after editing the attribute to make sure your changes are saved.

When an attribute value is "0" in SL1, the corresponding field in ServiceNow might display as empty.
Click Save. The Configuration pane automatically closes after this message appears.
Click Run () to run the application.
When the application completes, open the Step Log and review the log messages for the "Process Organizations" step to see if any company or organization records were created. As needed, select the other steps to review the logs on the Step Log for those steps.

Any SL1 organization that is synced to a ServiceNow Company will have the crm_id field on the Properties tab for that organization populated with the ServiceNow Company sys_id variable.

ScienceLogic recommends that you schedule an Organization Sync to run at least once a week. For more information, see Scheduling PowerFlow Applications.

Syncing Devices from SL1 to ServiceNow

The "Sync Devices from SL1 to ServiceNow" application syncs devices and virtual device relationships from SL1 to ServiceNow. You can also sync devices based on organization and collector group.

The Device Sync process use rules or "mappings" that you can define in the "Sync Devices from SL1 to ServiceNow" application. These mappings connect an SL1 device class to a ServiceNow CI class, which determines the CI class that ServiceNow uses when creating the CI in ServiceNow.

For more information about building service rules (containment rules and hosting rules) for devices and CIs, see Configuring Service Rules for Device Sync.

The "Sync Devices from SL1 to ServiceNow" application can also collect manufacturer and model attributes from asset records aligned with devices in SL1 and sync that information with ServiceNow. PowerFlow only populates the manufacturer and model attributes if the values exist in ServiceNow CIs; PowerFlow does not create new manufacturer values in ServiceNow. The "Sync Devices from SL1 to ServiceNow" application uses the sys_id field as a reference when syncing manufacturer and model information between SL1 and ServiceNow. For more information, see Device Attribute Mappings.

Merged Devices in SL1

When the "Sync Devices from SL1 to ServiceNow" application encounters a merged device in SL1, it splits the record into two objects to allow for correct default relationships in ServiceNow.

Starting with version 3.2.0 of this SyncPack, the "Sync Devices from SL1 to ServiceNow" application syncs both the physical and the component device in SL1 to ServiceNow. When a merged device is encountered in SL1, the "Sync Devices" application splits the device in PowerFlow and creates two CIs in ServiceNow. This action does not impact the source device record in SL1.

In ServiceNow, the physical CI includes the relevant asset information. A relationship also exists between the physical CI and the virtual CI. The asset information is directly copied between both CIs, so the data will essentially be duplicated across both devices, and the data will be submitted to two separate tables. The sl1_url will also be the same on both devices, so that both CIs will point to the same device in SL1.

Using Other Data Sources with Merged Devices

If you have other data sources syncing into the ServiceNow CMDB and you have merged devices in SL1, ScienceLogic recommends caution when integrating to the CMDB.

Also, ScienceLogic recommends that you ensure that configuration of the Identification and Reconciliation (IRE) within ServiceNow affects all data sources that are integrating into it. In the case of ScienceLogic, this is most apparent when syncing merged devices. Modifications to the IRE to handle merged devices affects all other data sources that sync to those specific class tables. It is your responsibility to understand each data source, how that data source integrates with the ServiceNow CMDB, and how to leverage that knowledge to understand the impact IRE changes may have.

ScienceLogic cannot be held responsible for any duplicate, lost, or incorrect CI information as a result of merged devices when multiple data sources are involved. This scenario will also affect your Support SLAs, as this practice deviates from recommended best practices.

For more information about the ServiceNow Identification and Reconciliation module, see the ServiceNow documentation: https://docs.servicenow.com/bundle/orlando-servicenow-platform/page/product/configuration-management/concept/c_CompsandProcessIDandReconcil.html.

Common Fields Used by Device Sync

The "Sync Devices from SL1 to ServiceNow" application uses the following ServiceNow fields to determine which devices to sync from SL1 to ServiceNow:

SL1 Monitored. This field displays a Boolean (true or false) value that is impacted by whether the device is in SL1 or not. The device being found in ServiceNow depends on the SL1 Monitored field. The device being found in SL1 depends on the class mappings defined in the "Sync Devices from SL1 to ServiceNow" application.
- If the CI is in ServiceNow and the device is in SL1 , the SL1 Monitored flag is set to true.
- If the CI is in ServiceNow but the device is not in SL1, the SL1 Monitored field is set to false. Anything pulled from ServiceNow (everything that is monitored: true and matches the region) that does not have a matching device pulled from SL1 gets marked as monitored: false.

SL1 Region. This field represents an ID for the SL1 instance or instances being synced to the ServiceNow instance. The SL1 Region field is determined by the user when configuring the IS applications. In a multi-SL1 environment, ScienceLogic recommends that you make the SL1 Region field descriptive so the ServiceNow user knows from which SL1 stack the CI originated.
- If the SL1 Region field is defined as an identifier by the CI class, ServiceNow will create new CI records with the new SL1 Region value, and the user must manually delete the duplicate CIs in the old SL1 Region field.
- If the SL1 Region field is not defined as an identifier by the CI class, ServiceNow will not treat these devices as new CIs, and the SL1 Region field will be automatically updated.
  Changing the SL1 Region value after an initial run of the "Sync Devices from SL1 to ServiceNow" application will have differing results depending on the service rules defined in ServiceNow that dictate reconciliation of the CI. If you change the SL1 Region value, you will ll need to run "Sync Devices from SL1 to ServiceNow" twice: once to align the CIs with the new region, and a second time to enable PowerFlow to re-cache the newly updated CIs in the region.

SL1 ID or sl1_id. This field represents the value of the object from SL1 that is being synced. Do not use sl1_id as a CI Identifier.

Running a Device Sync

To perform a Device Sync between SL1 and ServiceNow, run the following applications in the PowerFlow user interface, in the specified order:

Cache ServiceNow Companies, CIs and SL1 Orgs, Device Classes. Reads all existing SL1 device classes and ServiceNow CI classes and caches them for the Device Sync. This application uses this data to populate the mappings drop-down values in the "Sync Devices from SL1 to ServiceNow" application. Before version 3.5.0 of this SyncPack, this application was named "Cache ServiceNow CIs and SL1 Device Classes".
Generate Required CI Relations for ServiceNow. Determines if you are missing any class mappings or service rules that might be required in ServiceNow.
Sync Devices from SL1 to ServiceNow. Syncs devices and virtual device relationships from SL1 to ServiceNow. In previous versions, this application was named "ScienceLogic To ServiceNow Device Sync using GraphQL".

The speed of ServiceNow processing is reduced by ServiceNow errors generated when consuming payloads. If you experience slow processing or "maximum execution time exceeded" messages, you must review and address any ServiceNow errors reported to resolve. If there are significant ServiceNow errors in Device Sync, those errors will also impact Interface sync processing. When running dependent syncs at large scale, such as Interface Sync and Device Sync, ScienceLogic recommends that you run them serially, not at the same time. Running both syncs at the same time will greatly hinder ServiceNow processing and scalability.

To sync SL1 devices with ServiceNow:

In the PowerFlow user interface, select the "Cache ServiceNow CIs and SL1 Orgs, Device Classes" application from the Applications page, click Configure (), align a configuration object, and then click Run ().

If you change any of the containment rules or hosting rules in ServiceNow, you will need to run "Cache ServiceNow CIs and SL1 Orgs, Device Classes" again. For more information, see Configuring Service Rules for Device Sync.
Select the "Generate Required CI Relations for ServiceNow" application from the Applications page, click Configure (), align a configuration object, and then click Run ().

PowerFlow uses the Device Class mappings you are going to configure in step 6, so you do not need to set up any mappings on the Configuration pane for the "Generate Required CI Relations for ServiceNow" application. Any mappings you add to this application will overwrite mappings in the "Sync Devices from SL1 to ServiceNow" application.
When the "Generate Required CI Relations for ServiceNow" application completes, review the log information in the Step Log for the "Pull and Process Relations" step. You should see a log message stating that no missing relations were found. For more information, see Log Messages for the "Generate Required CI Relations for ServiceNow" Application.

If needed, address any missing class mappings or service rules. For more information on service rules, see Creating a ServiceNow Update Set.
Select the "Sync Devices from SL1 to ServiceNow" application from the Applications page and click Configure (). The Configuration pane appears:

Complete the following fields, as needed:

Configuration. Select the configuration object with the relevant SL1 and ServiceNow credentials to align with this application. You cannot edit fields that are populated by the configuration object. Required.

The region field (along with other fields related to user names and passwords) is populated by the configuration object you aligned with this application, using the Configuration field. The region value on this pane must match the value in the SL1 Region field in ServiceNow. If you need to update this value, you will need to define the region variable in the configuration object aligned with this application, or align a different configuration object that has the correct region value.
read_timeout. Specify the maximum amount of time in seconds that the application should wait for a HTTP Read response before timing out. The default is 300 seconds.
Include_Orgs. If you want to include a specific set of SL1 Organizations in the device sync, add the Organization IDs from the SL1 Organizations page (Registry > Accounts > Organizations) in this field, separated by commas. If this field is enabled, PowerFlow will pull only the Organizations listed in this field; PowerFlow does not pull all Organizations and then drop those not on the list. Leave this field empty to sync all SL1 Organizations. Optional.
Include_CUGs. If you want to include SL1 Collector Groups (CUGs) in the device sync, add the Collector Group IDs from SL1 in this field, separated by commas. Leave this field empty to sync all SL1 Collector Groups. Optional.

A misconfiguration in the Include Orgs field or the Include_CUGs fields might change the monitoring flag for one or more devices. In other words, a misconfiguration in this field could switch the SL1 Monitored flag from "true" to "false", removing that device or devices from the device sync.
sl1_chunk_size. Specify the number of devices to pull from SL1 in each chunk. The default is 500 devices per chunk.
snow_request_limit. Specify the number of CIs fetched from ServiceNow in each request. The default is 500 objects per chunk.
selected_devices. If you want to sync a sub-set of all discovered devices, type a comma-separated list of the Device IDs from SL1 for only the devices that you want to sync. Leave this field empty to sync all SL1 devices.
sl1_url_override. Update this field if you want to use an URL that is different from the standard SL1 URL that gets sent to the ServiceNow CI record. Optional.
excluded_devices. Type a list of comma-separated device names or device IDs for any devices that you want to exclude from the device sync. A device on the excluded list will still be queried, but it will be dropped during the PowerFlow sync process. Optional.
cache_lookup_chunk_size. Specify the number of CI correlation documents to pull from the PowerFlow cache in a chunk. The default is 1000 documents per chunk.
discovery_source. Specify the ServiceNow Discovery source. The default is "Other Automated".
snow_batch_size. Specify the total number of CIs being sent to ServiceNow in each triggered application. The default is 150 objects per batch.
snow_chunk_size. Specify the number of CI objects to send in each chunk or in each sub-payload with a batch (specifed in the snow_batch_size field). The default is 150 objects per chunk or sub-payload.
verify_snow_ssl. Toggle on (blue) this option to enable verification of the SSL certification when you run this application.
exclude_inactive. Select this option to prevent syncing devices to ServiceNow that are not enabled, unavailable, or in maintenance. By default, this option is not selected.
enable_device_active. Select this option to enable the Device Active block in the device GraphQL query, which contains information about the active state of the SL1 device. By default, this option is not selected. Accessing this data in the attribute mappings requires a Jinja2 Template. For more information, see Using a Jinja2 Template.
enable_asset_networks. Select this option to enable the assetNetworks block in the device GraphQL query, which returns a list of asset networks. By default, this option is not selected. Accessing this data in the attribute mappings requires a Jinja2 Template. For more information, see Using a Jinja2 Template.

Please note that enabling this option might cause performance issues on the SL1 side.
use_ap2_url. Select this option if you want the device URLs in the SL1 URL field in ServiceNow CIs to point to the corresponding Device Investigator page in the SL1 user interface: /inventory/devices/<SL1_device_ID>/investigator. This option is enabled by default. If you turn off this option, the device URL points to the classic EM7 user interface: /em7/index.em7?exec=device_summary&did=<SL1_device_ID>.
unmerge_devices. De-select this option if you want to turn off the "unmerge" behavior added in version 3.2.0 of this SyncPack, where PowerFlow splits a merged device record into two objects to allow for correct default relationships in ServiceNow. This option is enabled by default.
Domain_Separation. Select this option if your ServiceNow environment is domain-separated, where the data, processes, and administrative tasks have been organized into logical groupings called domains. If your ServiceNow instance is domain-separated, the user listed in the snow_user field must be a member of the top domain and have access to all of the domains you intend to integrate. Also, ServiceNow should be the "source of truth" for organizations if your environment is domain-separated. If this option is selected, PowerFlow syncs the ServiceNow Company sys_id to with the corresponding SL1 Organization.
drop_sys_id. Select this option if you want to remove the sys_id in existing CIs from the sync. If you set drop_sys_id to true, make sure that ServiceNow can correctly identify and correlate your existing CIs with the properties that are available. By default, this option is not selected.
drop_company. Select this option if you want to remove the sys_id in existing Companies from the sync, which prevents the "company" field from being sent to ServiceNow. Selecting this option has no effect if you selected the Domain_Separation option for this application. By default, this option is not selected.

If you select this option, the ServiceNow company sys_id for the CI and the SL1 organization crm_id for the SL1 device will not be compared when determining if an update has occurred. Do not select this option if you selected the Domain_Separation option, as ServiceNow requires PowerFlow to send the "company" field in domain-separated environments. Also, do not select this option if you selected the change_device_organizations option, as changing the company for a CI in ServiceNow requires the "company" field to be sent.
change_device_organizations. When enabled, this parameter allows devices to change companies with a Device Sync if the companies are within the same domain in ServiceNow. If you change the Organization/Company and another field or fields, but do not enable this parameter, PowerFlow will not apply any changes to the device. By default, this option is not selected.
generate_report. Select this option to create a report about the devices that you sync with ServiceNow. PowerFlow generates a report every time you run the device sync application, and the reports are available on the Reports page of the PowerFlow user interface.
Simulation_Mode. Select this option if you want to perform a simulated run of this application to show you the potential results of that run. By default, this option is not selected.
gql_filter. Using JSON, you can optionally define a custom GraphQL filter to apply to the devices in the sync. To test out a GraphQL filter, go to the GraphiQL interface in SL1 by typing the URL or IP address for SL1 in a browser, add /gql to the end of the URL or IP address, and press Enter. Search the built in GraphQL docs for DeviceSearch and determine how to set up your custom filter. An example of a Device Search query using JSON: {"name": {"doesNotBeginWith": "jc-is-ma"}}

You can use this field to filter devices by Device Group. For more information, see Filtering Device Sync by Device Group.

A misconfiguration in this field might change the monitoring flag for one or more devices. For example, a misconfiguration in this field could switch the SL1 Monitored flag from "true" to "false", removing that device or devices from the device sync. This field is an advanced feature that requires a basic knowledge of the SL1 GraphQL implementation. For more information, see Using the ScienceLogic GraphQL API.
customer_ci_relation_overrides. To override existing relationship linking and directly control the link between Device Classes and attributes, add JSON code to this field. The JSON for this field includes default relationship overrides for VMware instead of direct parent/child relations. For more information, see Configuring Customer CI Relation Overrides and Mappings between SL1, ServiceNow, and Other Applications.

In the mappings section, click the expand button () to view the mappings between SL1 device classes and ServiceNow CI classes. This section is pre-loaded with a large number of default device class mappings. You can map a single ServiceNow CI class with multiple SL1 device classes.

The "Sync Devices from SL1 to ServiceNow" application will only sync a device from SL1 if the device class for that device is mapped to a ServiceNow CI class in the mappings section. The default mappings in this section do not cover all technologies, however, and syncing additional technologies from SL1 to ServiceNow might require additional research to understand the class structure.
To create a custom mapping for the device sync, click Add Mapping at the bottom of the mappings section. ServiceNow CI classes display on the left, and SL1 device classes display on the right.
In the company_mapping_override section, you can create a new mapping for the ServiceNow company field for ServiceNow CIs (the first field on the left in the user interface). You can override the company field with a different ServiceNow field where you can read and write the company_sys_id for CIs.
In the attribute_mappings section, click the expand button () to view the mappings. In this section, you can create a mapping for any other custom device attributes you want to sync between SL1 (the first column) and ServiceNow (the second column):

All custom attributes for each SL1 device are automatically synced.

You can use a Jinja2 Template for device attribute fields on the SL1 side (the left column). For more information, see Using a Jinja2 Template.
To edit an existing device attribute in the attribute_mappings section, click the attribute name and either select an attribute from the list or type a new name for the attribute. Press Enter after editing the attribute to make sure your changes are saved.
To create a custom device attribute in the attribute_mappings section, click the Add Mapping button at the bottom of the section, type a name for the attribute in the first field, and select one or more ServiceNow attributes to which the SL1 attribute should sync in the maps to field. Press Enter after editing the attribute to make sure your changes are saved.

When an attribute value is "0" in SL1, the corresponding field in ServiceNow might display as empty.

To sync Device Notes between SL1 and ServiceNow, create a custom attribute for the device note in this section. This option works best if you only want a single value synced over so that value can remain in the notes.
Click Save. The Configuration pane closes.
Run the "Sync Devices from SL1 to ServiceNow" application.
When the application completes, open the Step Log and review the log messages for the "Compare SL1 Devices and ServiceNow CIs" step to see if any Device or CI records were added, updated, or disconnected from the sync. As needed, select the other steps to review the logs on the Step Log for those steps.

Depending on the number of devices you are syncing to ServiceNow, it might take a few minutes for all devices to get fully synced to the CMDB. You might notice after running device sync that the number of SL1 Monitored CIs continues to increase after each refresh. This is expected behavior due to payload chunking in ServiceNow. ServiceNow processes each payload as an individual chunk.

ScienceLogic recommends that you schedule a Device Sync to run every 24 hours. For more information, see Scheduling PowerFlow Applications.

Using a Jinja2 Template

The attribute mappings in Device Sync applications now support Jinja2 Templates, which let you sync complex, concatenated (linked) fields from SL1 to ServiceNow. For example, you can add these complex values in the SL1 side of the attribute_mappings section of the Configuration pane for the "Sync Devices from SL1 to ServiceNow"application, and that value is mapped to one or many fields in ServiceNow. For more information about Jinja2 Templates, see the Template Designer Documentation.

In the "Sync Devices from SL1 to ServiceNow" application, the SL1 side can be a Template. In the "Sync CI Attributes from ServiceNow to SL1" application, the ServiceNow side can be a Template.

Example: A Basic Template for Device Attributes

This example is included in the "Sync Devices from SL1 to ServiceNow" application as the first default value in the attribute_mappings section of the Configuration pane:

This template, when used on the SL1 side of the attribute_mappings section, populates the short_description field in ServiceNow:

"Description: {{device.device_category}}, Device Class: {{device.device_class}}": [ "short_description" ]

In the above example, for a device with a category: Testing and a Device Class of Testing | Testing, the end result would be Description: Testing, Device Class: Testing | Testing, which will be posted to the short_description field in ServiceNow.

The Jinja2 Templates will have access to all properties on the Device.

Any item that is generated by a template is always a string.

Example: An Advanced Template for Device Sync

The following example lets you get the active status of SL1 Devices:

{%- set output = [] -%}
{%- if device.active.unavailable == True -%}{%- set output = output + ['Unavailable'] -%}
{%- endif -%}
{%- if device.active.userDisabled == True -%}{%- set output = output + ['User Disabled'] -%}
{%- endif -%}
{%- if device.active.userInitiatedMaintenance == True -%}{%- set output = output + 
['User Initiated Maintenance'] -%}{%- endif -%}
{%- if device.active.userMaintenance == True -%}{%- set output = output + 
['User Initiated Maintenance'] -%}{%- endif -%}
{%- if output|length > 0 -%}
{{ ", ".join(output) }}
{%- else -%}
{{ "Active" }}
{%- endif -%}

Example: Another Advanced Template for Device Sync

The following example shows another way to get the active status of SL1 Devices:

{%- set prettify = {"userInitiatedMaintenance": "User Initiated Maintenance", "systemDisabled": 
"System Disabled", "maintenance": "System Maintenance", "unavailable": "Unavailable", 
"userDisabled": "User Disabled"} -%}
{%- set ns = namespace(maint=[]) -%}
{%- for k,v in device.active.items() -%}
{%- if v -%}
{%- set ns.maint = ns.maint + [prettify[k]] -%}
{%- endif -%}
{%- endfor -%}
{{", ".join(ns.maint) if ns.maint else "Active"}}

Example: Advanced Template for Device Class, Sub Category, and Model

The following example shows how to gather device data based on Device Class and Sub Category if available, or Model if Device Class and Sub Category are not available:

{%- set output = [] -%}
{%- set output = device.device_class.split('|') -%}
{%- if (output[0]|trim) in ['Checkpoint', 'ScienceLogic', 'Microsoft'] -%}
{%- set output = output[1]|trim -%}
{% else %}
{%- set output = device.model -%}
{%- endif -%}
{{output}}

Filtering Device Sync by Device Group

You can use the gql_filter field on the Configuration pane of the "Sync Devices from SL1 to ServiceNow" application to add a block of JSON code that lets you define a custom filter to apply to the devices in the sync.

You cannot enter GraphQL code in the gql_filter field in PowerFlow. The field only accepts JSON.

Using GraphQL to Create the Custom Filter

In this example, you will create a custom GraphQL filter in SL1 based on Device Groups. This filter will prevent Devices that belong to specific Device Groups from creating CIs in the ServiceNow CMDB.

To create a JSON filter for the gql_filter field:

Go to the GraphiQL interface in SL1 by typing the URL or IP address for SL1 in a browser, adding /gql to the end of the URL or IP address, and pressing Enter.

Create a GQL query that uses a search variable, such as the following example:

query DeviceFetch($search: DeviceSearch, $order: [ConnectionOrder], $first: Int) {
  devices(first: $first, search: $search, after: "", order: $order) {
    pageInfo {
      hasNextPage
      matchCount
    }
    edges {
      cursor
      device: node {
        ...

      }
    }
  }
}

After the query gives you the results you want, copy the resulting JSON variable definitions from the Query Variables section:
Paste that JSON code into the gql_filter portion of PowerFlow and save the PowerFlow application.

JSON Code Template

Instead of using the GraphiQL user interface in SL1, you can use the following JSON code as a template for filtering based on Device Group; simply paste the code into the gql_filter field on the Configuration pane and edit the search criteria and group names as needed:

{
  "deviceGroup": {
    "has": {
      "or": [
        {
          "name": {
            "contains": "group1"
          }
        },
        {
          "name": {
            "contains": "group2"
          }
        }
      ]
    }
  }
}

Tips for customizing the JSON code:

To add or remove additional Device Groups, copy or delete the following block of code and edit the group name as needed:

        {
          "name": {
            "contains": "group2"
          }
        }

If you add additional name blocks, add a comma after each name block except for the last name block. If you delete a block, delete the preceding comma.
You can change the "or" to an "and" if you want to block syncing for devices that are in more than one Device Group.
The "contains" can be changed to "eq" to make the name an exact match. For example, "contains": "office" would match "The Office," "HQ Office," and "Office235."

Adding Device Class Mappings

You can dynamically set the device mappings on a per-run basis using the API. You can also persistently save device mappings with the API. You can find these mappings in the mappings section of the Configuration pane for the "Sync Devices from SL1 to ServiceNow" application.

The following image displays an example of using Postman to send the mapping data to PowerFlow:

This example only maps device classes to ServiceNow for VMware, SL1 devices, and a few Cisco devices. If the your environment contains other device classes, you must manually create the mappings.

To add device class mappings using Postman, POST the following JSON file to trigger the required applications in the PowerFlow user interface to model SL1 devices to ServiceNow:

{

"name": "device_sync_sciencelogic_to_servicenow",

"params": {

"mappings": {

"cmdb_ci_ip_switch":[

"Cisco Systems | Catalyst 3850-48P",

"Cisco Systems | Nexus 9372PX"

"cmdb_ci_linux_server": [

"ScienceLogic, Inc. | EM7 Message Collector",

"ScienceLogic, Inc. | EM7 Customer Portal",

"ScienceLogic, Inc. | EM7 All-In-One",

"ScienceLogic, Inc. | EM7 Integration Server",

"ScienceLogic, Inc. | EM7 Admin Portal",

"ScienceLogic, Inc. | EM7 Database",

"ScienceLogic, Inc. | OEM",

"ScienceLogic, Inc. | EM7 Data Collector",

"NET-SNMP | Linux",

"RHEL | Redhat 5.5"

"cmdb_ci_esx_resource_pool": ["VMware | Resource Pool"],

"cmdb_ci_esx_server": [

"VMware | ESXi 5.1 w/HR",

"VMware | Host Server",

"VMware | ESX(i) 4.0",

"VMware | ESX(i) w/HR",

"VMware | ESX(i) 4.0 w/HR",

"VMware | ESX(i)",

"VMware | ESX(i) 4.1 w/HR",

"VMware | ESXi 5.1 w/HR",

"VMware | ESXi 5.0 w/HR",

"VMware | ESX(i) 4.1",

"VMware | ESXi 5.1",

"VMware | ESXi 5.0"

"cmdb_ci_vcenter_datacenter": ["VMware | Datacenter"],

"cmdb_ci_vcenter_datastore": ["VMware | Datastore", "VMware | Datastore Cluser"],

"cmdb_ci_vcenter_dv_port_group": ["VMware | Distributed Virtual Portgroup"],

"cmdb_ci_vcenter_dvs": ["VMware | Distributed Virtual Switch"],

"cmdb_ci_vcenter_folder": ["VMware | Folder"],

"cmdb_ci_vcenter_network": ["VMware | Network"],

"cmdb_ci_vmware_instance": ["VMware | Virtual Machine"],

"cmdb_ci_vcenter": ["VMware | vCenter", "Virtual Device | Windows Services"],

"cmdb_ci_vcenter_cluster": ["VMware | Cluster"]

"configuration": "template_snow_integration" #name your configuration file

}

Persistently Saving Device ClassMappings with the API

You can persistently save device class mappings using the API.

Use Postman or cURL to do a GET to load the "Sync Devices from SL1 to ServiceNow" application:

GET PowerFlow_hostname/api/v1/applications/device_sync_sciencelogic_to_servicenow

where PowerFlow_hostname is the IP address or URL for your PowerFlow system.

NOTE: The response should contain the entire JSON output for the application.

Copy the entire JSON code and save it to a file named: "device_sync_sciencelogic_to_servicenow".

Open the file you created and locate the object with the "name":"mappings" property in the "app_variables" list. The "value" property in this object specifies the mappings to use throughout the PowerFlow applications:

Modify the "value" property of the object to use the mappings you want to use.
Ensure that the mappings follow the same JSON data structure, or else the sync will not work:

{

"cmdb_ci_class": [

"ScienceLogic Dev Class| ScienceLogic subclass",

"Another Silo Dev Class | Another Silo subclass"

]

}

After you update the mappings, use the iscli tool to upload the updated application with your new settings. Type the following command at the command line:

iscli –uaf device_sync_sciencelogic_to_servicenow –H PowerFlow_hostname -p password

where:
- PowerFlow_hostname is the hostname or IP address of the PowerFlow system.
- password is the password you use to log in to the PowerFlow system.

Checking for Missing Device Mappings

You can use the "Report: Identify Unmapped Devices Classes" PowerFlow application to check whether any device mappings are missing in your PowerFlow server.

This application pulls the class mappings from Device Sync and Attribute Sync and compares the mappings with the full list of device classes of discovered devices in SL1. The application generates a report on the Reports page that lists missing mappings, and if any device classes are unmapped, the application generates an event in the target SL1 system.

To configure the "Report: Identify Unmapped Devices Classes" application:

If you do not have the ServiceNow Base PowerPack version 104 or later on your SL1 system, search for and download the PowerPack from the PowerPacks page on the ScienceLogic Support Site at https://support.sciencelogic.com/s/powerpacks.
In SL1, enable the "ServiceNow CMDB: Un-Mapped Device Classes" Event Policy from the ServiceNow Base PowerPack version 104 or later to trap the alert generated by this application.
In the PowerFlow user interface, go to the Configurations page.
Click the Actions button () for the configuration object you want to use with this application and select Edit. The Configuration pane for the object appears.
In the Configuration Data Values section, click Add Value. A new name-value line appears.
Add a configuration variable named pf_host that has a value of the externally addressable IP or fully qualified domain name (FQDN) of the PowerFlow cluster or instance.
Click Save.
Go to the Applications page and select the "Report: Identify Unmapped Devices Classes" application.
Click Configure () to open the Configuration pane:
Complete the following fields, as needed:

Configuration. Select the configuration object you updated in steps 1-5 to align with this application. Make sure that the pf_host value that is updated on the Configuration pane is accurate. You cannot edit fields that are populated by the configuration object. Required.
read_timeout. Specify the maximum amount of time in seconds the application should wait for a response before timing out. The default is 20 seconds.
query_retries. Specify the number of times to retry this query if needed. The default chunk size is 0.

Click Save and wait for the "App & Config modifications saved" pop-up message to appear. The Configuration pane automatically closes after this message appears.
Click Run () to run the application.

After the application runs, click the Reports button () and select the relevant report-missing-classes report from the Reports page. The "missing_classes" report appears:

The report displays missing mappings for Device Sync (SL1 to ServiceNow) in the first column, and missing mappings for Attribute Sync (ServiceNow to SL1) in the second column.

Also, if any device classes are unmapped and you enabled the "ServiceNow CMDB: Un-Mapped Device Classes" Event Policy in step 2, SL1 generates an event on the Events page in SL1:

Device Attribute Mappings

These manufacturer and model attributes are different from custom attributes in SL1.

PowerFlow only populates the manufacturer and model attributes if the values exist in ServiceNow CIs; PowerFlow does not create new manufacturer values in ServiceNow. "Sync Devices from SL1 to ServiceNow" application uses the sys_id field as a reference when syncing manufacturer and model information between SL1 and ServiceNow.

Integer fields in ServiceNow have a maximum value of 2147483647. If a value exceeds that value, ServiceNow stores it as 2147483647. This is a MySQL limitation on the maximum value that can be stored in a signed integer variable.

The "Sync Devices from SL1 to ServiceNow" application only syncs assets that have a value populated in SL1. SL1 automatically populates fields in an asset record when the record is properly configured. For more information on configuring assets in SL1, see Asset Management.

Default Device Attribute Mappings

The "Sync Devices from SL1 to ServiceNow" application contains a set of default device attribute mappings between SL1 and ServiceNow. You can find these mappings in the attribute_mappings section of the Configuration pane for that application.

The following table describes the default device attribute mappings:

SL1 Device Attribute	ServiceNow CI Attribute
Description	"Description: {{device.device_category}}, Device Class: {{device.device_class}}": [ "short_description" NOTE: This field requires a Jinja2 Template. For more information, see Using a Jinja2 Template.
asset_tag	asset_tag
cpuCount	cpu_count
cpuMake	cpu_type
cpuSpeed	cpu_speed
dateAdded	first_discovered
diskSize	disk_space
dnsDomain	dns_domain
function	justification
hostname	fqdn, host_name
instance_uuid	account_id
ip	ip_address
manufacturer_sys_id	manufacturer
memory	ram
model_sys_id	model_id
name	name
operatingSystem	os
purchaseDate	order_date
serial	serial_number
status	hardware_substatus
warrantyExpirationDate	warranty_expiration

SL1 Device Attributes Available for Syncing

In the attribute_mappings section of the Configuration pane for the "Sync Devices from SL1 to ServiceNow" application, you can also use the following SL1 device attributes from SL1 when syncing attributes with ServiceNow:

arraySize
asset_id
asset_tag
company_sys_id
component_unique_id
cpuCount
cpuMake
cpuSpeed
dateAdded
depreciationMethod
depreciationSchedule
device_category
device_class
diskCount
diskSize
dnsDomain
dnsName
domain_sys_id
firmwareVersion
floor
function
hostId
hostname
ip
location
make
manufacturer_sys_id
memory
model
model_sys_id
name
operatingSystem
org_id
org_name
owner
panel
parent_device
parent_did
plate
punch
purchaseCheck
purchaseCost
purchaseDate
purchaseOrderNumber
rack
region
rfid
room
serial
serviceCheck
serviceCost
serviceDate
serviceDescription
serviceExpirationDate
serviceOrderNumber
servicePolicyNumber
shelf
sl1_id
sl1_url
snow_ci_class
snow_sys_id
status
vitalAssetInformation
vitalServiceInformation
warrantyCheck
warrantyCost
warrantyDate
warrantyDescription
warrantyExpirationDate
warrantyOrderNumber
warrantyPolicyNumber
zone

Adding New Device Attributes to ServiceNow

You can also add one or more new attributes to ServiceNow that you can then sync with SL1.

To add an attribute in ServiceNow:

In ServiceNow, search for "Tables" in the filter navigator and select System Definition > Tables.
From the Tables page, search for and select the table to which you want to add a field for a new attribute.
From the Table page, click the New button to add a new field on the table. A new record appears:
From the Type drop-down list, select the data type you want to store, such as String. Depending on your selection, additional required fields display:

In the String example, above, Column label contains the text you want to display in ServiceNow, and Column name is the exact column name used by PowerFlow or the API.
Complete the required fields and any other fields as needed, and then click the Submit button. The field is added to ServiceNow.

Configuring Customer CI Relation Overrides

When you are mapping Device Classes and attributes, you might find that SL1 creates relationship mappings very differently than the way that ServiceNow creates relationships. As a result, ScienceLogic strongly recommends that you use the customer_ci_relation_overrides field instead of using ServiceNow to set up those relationships.

In the "Sync Devices from SL1 to ServiceNow" PowerFlow application, you can use the customer_ci_relation_overrides field to override the existing relationship linking and directly control the link between Device Classes and attributes. The customer_ci_relation_overrides field lets you build dynamic relationships rather than statically setting up relationships within ServiceNow.

ScienceLogic does not support using ServiceNow to control and set up your device relationships.

In addition, ScienceLogic strongly recommends that you use the default relationship overrides for VMware, which you can view by clicking Show JSON Configs from the Configuration pane for the "Sync Devices from SL1 to ServiceNow" PowerFlow application.

This mapping process is intended for advanced users that are familiar with how SL1 and ServiceNow construct device relationships.

In the following example, the relationship structure in SL1 is linear :

In ServiceNow, however, the structure is not as linear, and it requires an override (a manual link) between classes to make the relationship link required:

The following image shows the JSON structure formatting that is required for the customer_ci_relation_overrides field:

The values in the customer_ci_relation_overrides field supersede any of the values configured in the mappings section in the Configuration pane for the "Sync Device Classes from SL1 to ServiceNow" PowerFlow application.

You must ensure that all classes in the relationship chain in SL1 are mapped to classes in ServiceNow, or else the chain will break, and PowerFlow will not correctly apply the overrides.

In the customer_ci_relation_overrides field, you can string together multiple relationships as in the following example:

{
   "cmdb_ci_db_mssql_instance": {
       "relations": [
           {
               "parent": "cmdb_ci_win_server",
               "rel_type": "Runs on::Runs",
               "reverse": true
           }
       ],
       "values": {"sys_class_name": "snow_ci_class", "instance_name": "name"}
   },
   "cmdb_ci_db_mssql_database": {
       "relations": [
           {
               "parent": "cmdb_ci_db_mssql_instance",
               "rel_type": "Contains::Contained by",
               "reverse": false
           }
       ],
       "values": {"sys_class_name": "snow_ci_class", "database": "name"}
   },
   "cmdb_ci_db_mssql_server": {
       "relations": [
           {
               "parent": "cmdb_ci_win_server",
               "rel_type": "Runs on::Runs",
               "reverse": true
           }
       ],
       "values": {"sys_class_name": "snow_ci_class", "instance_name": "name"}
   }
}

Viewing Reports for Device Sync

The "Sync Devices from SL1 to ServiceNow" application lets you create a report about the devices that you sync with ServiceNow. The report displays on the Reports page ():

Enable the report by selecting the generate_report option on the Configuration pane for the application.

When the relevant data is present in a device sync, the report displays the following data under the Details pane:

Creations Sent to ServiceNow. Device information for devices in SL1 that will be created in ServiceNow.
Device Counts. Lists the number of created, disconnected, and updated devices, as well as the number of devices pulled from SL1 and ServiceNow during the sync. If domain separation is on and there are devices removed due to domain separation errors, that count will be added to the table.
Deletions Sent to ServiceNow. Device information for devices in SL1 that will be deleted in ServiceNow.
Post CIs to ServiceNow. Each instance of the "Post CIs to ServiceNow" application, listing creations, disconnects, errors, skips, and updates made in ServiceNow.
Updates Sent to ServiceNow. Device information for devices in SL1 to be updated in ServiceNow.

Syncing CI Attributes from ServiceNow to SL1

The "Sync CI Attributes from ServiceNow to SL1" application imports CI attributes from ServiceNow to the relevant asset and attribute fields in SL1. The CI Sync supports assets, asset configuration, asset maintenance, location, production statuses, and custom attributes.

The "Sync CI Attributes from ServiceNow to SL1" application can sync the display value and sys_id of Reference fields, such as location, as well as the value and label of Choice List fields, such as operational_status. These values can be accessed by appending _label to the desired field name.

Reference Example:

"location": "240f6630db993300dc44f00fbf96196f"

"location_label": "Corporate Headquarters"

Choice List Example:

"operational_status": "1",

"operational_status_label": "Operational",

The following image shows the Location table, and the Display column shows the Name marked as true. Only one field on the table can be marked as true, and that is the field that will be returned to PowerFlow :

When this application runs, if no mappings are provided, PowerFlow queries the "Sync Devices from SL1 to ServiceNow" application and uses the mappings from that application.

To sync CI attributes from ServiceNow to SL1:

Go to the Applications page of the PowerFlow user interface and run the "Cache ServiceNow Companies, CIs and SL1 Orgs, Device Classes" application. This application reads all existing SL1 Device Classes, Organizations, ServiceNow CIs, and Companies and writes them to a cache.
When that application completes, go to the Applications page and run the "Sync Devices from SL1 to ServiceNow" application to enable PowerFlow to use the mappings and additional attribute options from Device Sync.
When that application completes, go to the Applications page and run the "Sync CI Attributes from ServiceNow to SL1" application.
Click Configure (). The Configuration pane appears:
Complete the following fields, as needed:

Configuration. Select the configuration object with the relevant SL1 and ServiceNow credentials to align with this application. You cannot edit fields that are populated by the configuration object. Required.

The region field (along with other fields related to user names and passwords) is populated by the configuration object you aligned with this application. The region value must match the value in the SL1 Region field in ServiceNow. If you need to update this value, you will need to define the region variable in the configuration object that is aligned with this application, or align a different configuration object that has the correct region value.
read_timeout. Specify the maximum amount of time in seconds that the application should wait for a response before timing out. The default is 20 seconds
chunk_size. Specify the number of devices to include in each chunk sent to ServiceNow when you run this application. The default chunk size is 500 devices.
Include_Orgs. If you want to include SL1 Organizations in the sync, add the Organization IDs from SL1 in this field, separated by commas. Leave this field empty to sync all SL1 Organizations. This option filters on the ServiceNow CI sync as well as the SL1 Device sync.
Include_CUGs. If you want to include SL1 Collector Groups (CUGs) in the sync, add the Collector Group IDs from SL1 in this field, separated by commas. Leave this field empty to sync all SL1 Collector Groups.
snow_request_limit. Specify the number of CIs fetched from ServiceNow in each request. The default is 500 objects per chunk.
retry_max. The maximum number of times PowerFlow will retry to execute the step before it stops retrying and logs a step failure. For example, if retry_max is 3, PowerFlow will retry after 1 second, then 2 seconds, then 4 seconds, and stop if the last retry fails. The default is 0.
retry_backoff_max.The maximum time interval for the retry_backoff option, in seconds. For example, if you have retry_max set to 15, the delays will be 1, 2, 4, 8, 16, 32, 64, 120, 240, 480, 600, 600, 600, 600, and 600. The default is 600.
verify_snow_ssl. Toggle on (blue) this option to enable verification of the SSL certification when you run this application.
sync_empty_fields. Select this option if you want to include empty fields on ServiceNow CIs when you run this application. This option is disabled by default.

SL1 does not return extended custom attributes for devices if no value is present. As a result, if the value for the custom attribute is empty in ServiceNow, PowerFlow will continually send updates for those devices, because the empty value written to is not returned in subsequent runs of the application. When the sync_empty_fields option is selected, the application sends a 0 or '', depending on the attribute type for the custom attributes in the mappings for all devices.
snow_attributes_created. Select this option to show that custom attributes for ServiceNow sys_id and ci_class already existing in SL1.
retry_jitter. When selected, instead of using a defined interval between retries, PowerFlow will retry the step execution at random intervals. The default is unselected.
retry_backoff. When selected, instead of using a defined interval between retries, PowerFlow will incrementally increase the interval between retries. The default is unselected.
gql_filter. Specify a custom GraphQL filter to apply to the devices in the sync. An example of a Device Search GraphQL query is: {"name": {"doesNotBeginWith": "jc-is-ma"}}
mappings. This section lets you view and add mappings between SL1 Device Classes and ServiceNow CI classes. If no mappings are provided in this section, the application step will only pull CI classes provided in the "Sync Devices from SL1 to ServiceNow" application. If you add mappings in this section, only CI classes that were included in this section will be returned from ServiceNow.
company_mapping_override. In this section, you can create a new mapping for the ServiceNow "company" field for ServiceNow CIs (the first field on the left in the user interface). You can override the "company" field with a different ServiceNow field where you can read and write the company_sys_id for CIs.
attribute_mappings. In this section, you can create a mapping for any other custom attributes you want to sync between SL1 (the first column) and ServiceNow (the second column).

You can use a Jinja2 Template for attribute fields on the ServiceNow side (the right column). For more information, see Using a Jinja2 Template.

To sync a user-defined field on the ServiceNow CI record to the device notes table in SL1, create a custom attribute mapping for that field in this section. This option works best if you only want a single value synced over so that value can remain in the notes.

Click Save. The Configuration pane automatically closes.
Click Run () to run the "Sync CI Attributes from ServiceNow to SL1" application.

Creating a Link in an SL1 Device to a ServiceNow CI

To help you mange your SL1 devices and their corresponding ServiceNow CIs, you can create a link in an SL1 Device that goes directly to the synced CI in ServiceNow.

The "Create Custom Attributes and ServiceNow Custom Link in SL1" PowerFlow application creates servicenow_sys_id and servicenow_ci_class custom device attributes in SL1, and then SL1 uses those two attributes to create a custom link in SL1 titled ServiceNow that redirects to the ServiceNow CI.

In SL1, the link appears as a custom link on the Tools menu for the corresponding device:

The application only creates the custom attributes if the attributes do not already exist. Additionally, if the custom link functionality is disabled by default on SL1, the application will enable the feature before creating the necessary attributes and link.

To create a link for the SL1 device:

In the PowerFlow user interface, go to the Applications page and open the "Sync CI Attributes from ServiceNow to SL1 to ServiceNow" application.
Click the Configure button. The Configuration pane appears.
Enable the snow_attributes_created toggle and click Save.
Click Run ( ) to run the application.
On the Applications page, open the "Create Custom Attributes and ServiceNow Custom Link in SL1" PowerFlow application, align a configuration object if needed, and click Run ( ) to run the application.

You only need to run the "Create Custom Attributes and ServiceNow Custom Link in SL1" application once.

Syncing Advanced Topology Data from SL1 to ServiceNow

Starting with version 3.5.0 of this SyncPack, the "Sync Advanced Topology from SL1 to ServiceNow" application was removed. The functionality in that application was added to the "Sync Devices from SL1 to ServiceNow" and "Sync Interfaces from SL1 to ServiceNow" applications.

For versions of this SyncPack that came out before version 3.5.0, the "Sync Advanced Topology from SL1 to ServiceNow" application reads Dynamic Component Mapping relationships from SL1 and syncs those relationships with ServiceNow. This application also syncs CDP, L2, L3, LLDP and DCM+R relationships.

If this is a new PowerFlow system, you must run both the "Sync Devices from SL1 to ServiceNow" application and the "Sync Interfaces from SL1 to ServiceNow" application at least twice on new PowerFlow systems to populate the cache for this application.

PowerFlow only syncs topology data for devices and network interfaces that have already been synced with ServiceNow. Before setting up advanced topology sync, you must first sync devices or sync network interfaces, depending on your environment.

To sync advanced topology data and relationships from SL1 to ServiceNow:

On the Applications page of the PowerFlow user interface, click Run () for the "Sync Devices from SL1 to ServiceNow" application. Run the application a second time if this is a new PowerFlow system.
Click Run () for the "Sync Interfaces from SL1 to ServiceNow" application. Run the application a second time if this is a new PowerFlow system.
Select the "Sync Advanced Topology from SL1 to ServiceNow" application and click Configure (). The Configuration page appears:
Complete the following fields, as needed:

Configuration. Select the configuration object with the relevant SL1 and ServiceNow credentials to align with this application. You cannot edit fields that are populated by the configuration object. Required.

The region field is populated by the configuration object you aligned with this application. The region value must match the value in the SL1 Region field in ServiceNow. If you need to update this value, you will need to define the region variable in the configuration object that is aligned with this application, or align a different configuration object that has the correct region value.
chunk_size. Specify the number of topologies to include in each chunk sent to ServiceNow when you run this application. The default chunk size is 500.
read_timeout. Specify the maximum amount of time in seconds the application should wait for a response before timing out. The default is 20 seconds.
retry_max. The maximum number of times PowerFlow will retry to execute the step before it stops retrying and logs a step failure. For example, if retry_max is 3, PowerFlow will retry after 1 second, then 2 seconds, then 4 seconds, and stop if the last retry fails. The default is 0.
retry_backoff_max.The maximum time interval for the retry_backoff option, in seconds. For example, if you have retry_max set to 15, the delays will be 1, 2, 4, 8, 16, 32, 64, 120, 240, 480, 600, 600, 600, 600, and 600. The default is 600.
Domain_Separation. Select this option if your ServiceNow environment is domain-separated, where the data, processes, and administrative tasks have been organized into logical groupings called domains. If your ServiceNow instance is domain-separated, the user listed in the snow_user field must be a member of the top domain and have access to all of the domains you intend to integrate. Also, ServiceNow should be the "source of truth" for organizations if your environment is domain-separated. This application does not support relationships for devices across domains; all devices in a relation payload must be in the same domain.
Simulation_Mode. Select this option if you want to perform a simulated run of this application to show you the potential results of that run.
retry_jitter. When selected, instead of using a defined interval between retries, PowerFlow will retry the step execution at random intervals. The default is unselected.
retry_backoff. When selected, instead of using a defined interval between retries, PowerFlow will incrementally increase the interval between retries. The default is unselected.
customer_ci_relation_overrides. To set a Dynamic Component Mapping + Relationships (DCM+R) relationship type other than "Connects to" and "Connected By", add JSON code to this field. Example relationships include VM to Datastore or VM to Network. For more information, see Configuring Customer CI Relation Overrides and Mappings between SL1, ServiceNow, and Other Applications.

Click Save. The Configuration pane automatically closes.
Click Run ( ) to run the application.

Adding Related Items and Lists to the CI Record in ServiceNow

In ServiceNow you can add Related Items and Related Lists to CI records so you can see all related records in ServiceNow. The following image shows the Related Items pane on a CI record for a VMware Virtual Machine Instance:

The following image shows how to add Related Items for a VMware Virtual Machine instance by selecting the CI relations option.

The following image shows the related lists for network adapters and files systems:

The items highlighted by the red boxes below are the most commonly used items:

For more information, see the ServiceNow Documentation at https://docs.servicenow.com/bundle/paris-platform-user-interface/page/use/using-forms/concept/c_RelatedLists.html.

Syncing Network Interfaces from SL1 to ServiceNow

You can map and sync network interfaces in much the same way you sync devices between SL1 and ServiceNow. The "Sync Interfaces from SL1 to ServiceNow" application collects interface data from ServiceNow and SL1 and runs multiple CI syncs for each interface to be synced.

Version 3.5.0 and later of this SyncPack requires SL1 version 11.2.0 or later.

PowerFlow only syncs network interfaces that are aligned with devices that are already synced with ServiceNow. Before setting up network interface sync, you must first sync devices between SL1 and ServiceNow.

To sync SL1 network interfaces with ServiceNow:

In the PowerFlow user interface, go to the Applications page and run the "Cache ServiceNow Companies, CIs and SL1 Orgs, Device Classes" application to read all existing SL1 Device Classes, Organizations, ServiceNow CIs, and Companies and write them to a cache.
When that application completes, go to the Applications page and select the "Sync Interfaces from SL1 to ServiceNow" application.
Click Configure (). The Configuration pane appears:
Complete the following fields, as needed:

Configuration. Select the relevant configuration object to align with this application. You cannot edit fields that are populated by the configuration object. Required.

The region field (along with other fields related to user names and passwords) is populated by the configuration object you aligned with this application, using the Configuration field. The region value on this pane must match the value in the SL1 Region field in ServiceNow. If you need to update this value, you will need to define the region variable in the configuration object aligned with this application, or align a different configuration object that has the correct region value.
sl1_chunk_size. Specify the number of interfaces to pull from SL1 in each chunk. The default is 500.
read_timeout. Specify the maximum amount of time in seconds the application should wait for a response before timing out.
Include_Orgs. If you want to include a specific set of SL1 Organizations in the interface sync, add the Organization IDs from the SL1Organizations page (Registry > Accounts > Organizations) in this field, separated by commas. If this field is enabled, PowerFlow will pull only the Organizations listed in this field; PowerFlow does not pull all Organizations and then drop those not on the list. Leave this field empty to sync all SL1 Organizations. Optional.

A misconfiguration in the Include Orgs field field might change the monitoring flag for one or more devices. In other words, a misconfiguration in this field could switch the SL1 Monitored flag from "true" to "false", removing that interface or interfaces from the device sync.
snow_request_limit. Specify the number of objects fetched from ServiceNow in each request. The default is 500 objects per chunk.
snow_batch_size. Specify the total number of objects being sent to ServiceNow in each triggered application. The default is 150 objects per batch.
discovery_source. Specify the ServiceNow Discovery source. The default is "Other Automated".
snow_chunk_size. Specify the number of objects to send in each chunk or in each sub-payload with a batch (specifed in the snow_batch_size field). The default is 150 objects per chunk or sub-payload.
enabled_only. Select this option only sync enabled interfaces. When enabled, this filter is applied to both the SL1 and ServiceNow side pulls. By default, this option is not selected.
interface_snow_default. Select this option to allow interface types that are not included in the mappings to be sent to the cmdb_ci_network_adapter table in ServiceNow.
Domain_Separation. Select this option if your ServiceNow environment is domain-separated, where the data, processes, and administrative tasks have been organized into logical groupings called domains. If your ServiceNow instance is domain-separated, the user listed in the snow_user field must be a member of the top domain and have access to all of the domains you intend to integrate. Also, ServiceNow should be the "source of truth" for organizations if your environment is domain-separated. By default, this option is not selected.
change_interface_organizations. Toggle on (blue) this option to allow interfaces to change companies with an Interface Sync if the companies are within the same domain in ServiceNow. If you change the Organization/Company and another field, but do not enable this parameter, PowerFlow will not apply any changes to the interface. By default, this option is not selected.
drop_company. Toggle on (blue) this option to remove the sys_id in existing companies from the sync. This will prevent the "Company" field from sending to ServiceNow. This option has no effect if the domain_separation parameter is enabled for this application. By default, this option is not selected.

If you select this option, the ServiceNow company sys_id for the interface and the SL1 organization crm_id for the SL1 device will not be compared when determining if an update has occurred. Do not select this option if you selected the Domain_Separation option, as ServiceNow requires PowerFlow to send the "company" field in domain-separated environments. Also, do not select this option if you selected the change_interface_organizations option, as changing the company for an interface in ServiceNow requires the "company" field to be sent.

verify_snow_ssl. Toggle on (blue) this option to enable verification of the SSL certification when you run this application.
generate_report. Select this option to create a "Sync Interfaces from SL1 to ServiceNow" report. This report contains counts of the number of interfaces gathered from SL1 and ServiceNow, the number of unchanged interfaces, as well as the number of creations, updates, and disconnects sent to ServiceNow. Detailed interface information for the interfaces sent to ServiceNow is also displayed. The reports are available on the Reports page of the PowerFlow user interface.
Simulation_Mode. Select this option if you want to perform a simulated run of this application to show you the potential results of that run. This option is not selected by default.

gql_filter. Using JSON, you can optionally define a custom GraphQL filter to apply to the interfaces in the sync. To test out a GraphQL filter, go to the GraphiQL interface in SL1 by typing the URL or IP address for SL1 in a browser, add /gql to the end of the URL or IP address, and press Enter. Search the built in GraphQL docs for InterfaceSearch and determine how to set up your custom filter.
interface_table_relations. Using JSON, define the relationship for any ServiceNow tables used in the mappings parameter, below. If a table is included in the mappings, but the relationship is not defined in the interface_table_relations, the Interface Sync application will fail.
mappings. In this section, you can map specific interface types to different tables in ServiceNow. Interfaces with types that are not defined in these mappings will be skipped. If the interface_snow_default option is selected, missing mappings will be sent to the cmdb_ci_network_adapter table.

You can add mappings for interface types that map to the cmdb_ci_network_adapter, dscy_switchport, or dscy_router_interface tables in ServiceNow. However, if the parent device type of the interface in SL1 is Network.Switches or Network.Router, the interface will be sent to dscy_switchport and dscy_router_interface tables, respectively, regardless of the mappings added here. If an IP address is found on the interface and the parent device is one of these types, an additional interface will also be sent to the cmdb_ci_network_adapter and will contain IFCOPY in the native key.
company_mapping_override. In this section, you can create a new mapping for the ServiceNow company field for ServiceNow CIs (the first column). You can override the company field with a different ServiceNow field where you can read and write the company_sys_id for CIs.
attribute_mappings. In this section, you can create a mapping for any other custom attributes you want to sync between SL1 (the first column) and ServiceNow (the second column):

Click Save. The Configuration pane closes.
Click Run () to run the application.
When the application completes, go to ServiceNow and type "cmdb_ci_network_adapter.list". The Network Adapters page appears, with a list of synced interfaces:

Select a network interface from the list and scroll down to the Network Adapters tab to see more information about the interface, such as the Operational status value, which is synced from SL1.

NOTE: The Operational status value is different from the SL1 Monitored value, but PowerFlow tracks both values.

Syncing File Systems from SL1 to ServiceNow

You can map and sync file systems in much the same way you sync devices between SL1 and ServiceNow. The "Sync File Systems from SL1 to ServiceNow" application reads file systems discovered in SL1 and then maps them to a parent CI record in ServiceNow.

For a file system to be synced from SL1 to ServiceNow, the class of the file system's parent device must be included in the mappings parameters for the "Sync Devices from SL1 to ServiceNow" application. Interfaces with parent CIs with className values of cmdb_ci_ip_switch" or cmdb_ci_ip_router" will be sent to ServiceNow, but by default they will not be created in ServiceNow due to missing relationship information.

PowerFlow only syncs file systems that are aligned with devices that are already synced with ServiceNow. Before setting up file system sync, you must first sync devices between SL1 and ServiceNow.

To sync SL1 file systems with ServiceNow:

In the PowerFlow user interface, go to the Applications page and run the "Cache ServiceNow Companies, CIs and SL1 Orgs, Device Classes" application to read all existing SL1 Device Classes, Organizations, ServiceNow CIs, and Companies and write them to a cache.
When that application completes, go to the Applications page and select the "Sync File Systems from SL1 to ServiceNow" application.
Click Configure () to open the Configuration pane:
Complete the following fields, as needed:

Configuration. Select the relevant configuration object to align with this application. You cannot edit fields that are populated by the configuration object. Required.

The region field (along with other fields related to user names and passwords) is populated by the configuration object you aligned with this application, using the Configuration field. The region value on this pane must match the value in the SL1 Region field in ServiceNow. If you need to update this value, you will need to define the region variable in the configuration object aligned with this application, or align a different configuration object that has the correct region value.
Include_Orgs. If you want to include a specific set of SL1 Organizations in the sync, add the Organization IDs from the SL1Organizations page (Registry > Accounts > Organizations) in this field, separated by commas. If this field is enabled, PowerFlow will pull only the Organizations listed in this field; PowerFlow does not pull all Organizations and then drop those not on the list. Leave this field empty to sync all SL1 Organizations. Optional.
snow_request_limit. Specify the number of objects fetched from ServiceNow in each request. The default is 500 objects per chunk.
read_timeout. Specify the maximum amount of time in seconds the application should wait for a response before timing out. The default is 30 seconds.
snow_batch_size. Specify the total number of objects being sent to ServiceNow in each triggered application. The default is 150 objects per batch.
discovery_source. Specify the ServiceNow Discovery source. The default is "Other Automated".
snow_chunk_size. Specify the number of objects to send in each chunk or in each sub-payload with a batch (specifed in the snow_batch_size field). The default is 150 objects per chunk or sub-payload.
include_hidden. Select this option to sync hidden file systems. This filter is only applied on the SL1 side of the sync. By default, this option is not selected.
include_stale. Select this option to sync stale file systems. This filter is only applied on the SL1 side of the sync. By default, this option is not selected.

Be cautious when applying these include options, as enabling one or both options might cause unwanted disconnects if the File System Sync is run with these options enabled and then run with the options disabled.
Domain_Separation. Select this option if your ServiceNow environment is domain-separated, where the data, processes, and administrative tasks have been organized into logical groupings called domains. If your ServiceNow instance is domain-separated, the user listed in the snow_user field must be a member of the top domain and have access to all of the domains you intend to integrate. Also, ServiceNow should be the "source of truth" for organizations if your environment is domain-separated.
change_fs_organizations. Toggle on (blue) this option to allow file systems to change companies with an Interface Sync if the companies are within the same domain in ServiceNow. If you change the Organization/Company and another field, but do not enable this parameter, PowerFlow will not apply any changes to the file system. By default, this option is not selected.
drop_company. Toggle on (blue) this option to remove the sys_id in existing companies from the sync. This will prevent the "Company" field from sending to ServiceNow. This option has no effect if the domain_separation parameter is enabled for this application. By default, this option is not selected.

If you select this option, the ServiceNow company sys_id for the file system and the SL1 organization crm_id for the SL1 device will not be compared when determining if an update has occurred. Do not select this option if you selected the Domain_Separation option, as ServiceNow requires PowerFlow to send the "company" field in domain-separated environments. Also, do not select this option if you selected the change_interface_organizations option, as changing the company for a file system in ServiceNow requires the "company" field to be sent.

verify_snow_ssl. Toggle on (blue) this option to enable verification of the SSL certification when you run this application.
sl1_org_filter_only. Toggle on (blue) this option to apply the organization filter to only the SL1 side of the data pull.

Enabling this toggle will only apply organization filtering to the SL1 side of the data pulls, while all file systems for the provided region in ServiceNow will be returned. Be cautious using this option, as enabling it may cause unwanted disconnects in ServiceNow.

generate_report. Select this option to create a "Sync File Systems from SL1 to ServiceNow" report. This report contains counts of the number of file systems gathered from SL1 and ServiceNow, the number of unchanged file systems, and the number of creations, updates, and disconnects sent to ServiceNow. Detailed file system information for the file systems sent to ServiceNow is also displayed. Finally, the report contains file systems that are in an unsupported format. The reports are available on the Reports page of the PowerFlow user interface.

Due to the differences between how SL1 and ServiceNow discover file systems, only certain formats of file systems contained in the SL1 database will be synced to ServiceNow. Only file systems where the name and the mount point can be determined from the name database field stored in the SL1 will be synced.
Simulation_Mode. Select this option if you want to perform a simulated run of this application to show you the potential results of that run.
company_mapping_override. In this section, you can create a new mapping for the ServiceNow "company" field for ServiceNow CIs (the first field on the left in the user interface). You can override the "company" field with a different ServiceNow field where you can read and write the company_sys_id for CIs.
attribute_mappings. In this section, you can create a mapping for any other custom attributes you want to sync between SL1 (the first column) and ServiceNow (the second column).

Click Save. The Configuration pane closes.
Click Run () to run the application.

Syncing Business Services

Depending on where you have your business services configured initially, you can use one of the two following methods to sync business services between SL1 and ServiceNow:

Syncing Business Services from SL1 to ServiceNow
Syncing Business Services from ServiceNow to SL1

To avoid duplicate services, you should only use one of the above processes in the PowerFlow user interface. The PowerFlow application you use depends on in which application (SL1 or ServiceNow) you initially configured your services, before syncing.

For example, if you have Business Services, IT Services, and Devices Services set up in SL1, you would use the "Sync Business Services from SL1 to ServiceNow" application, and SL1 would be the "source of truth" after the sync.

Syncing Business Services from SL1 to ServiceNow

The Sync Business Services from SL1 to ServiceNow application reads Business Services, IT Services, and Device Services from SL1 and syncs them with business services in ServiceNow. This application creates and updates services, but it does not delete services.

The "Sync Business Services from SL1 to ServiceNow" application does not currently support deleting or disconnecting services within ServiceNow. The application logs for the "Post to ServiceNow" step might contain information regarding disconnects, but you can ignore that information.

If a Device Service does not have a parent IT Service, the CMDB Group will be created, but the CI will not be created because of the way PowerFlow pulls each of those items. At the time of the Group creation, PowerFlow does not know if a service has a parent or not. At the time of the CI creation, PowerFlow does not directly pull Device Services; it only pulls Business Services and IT Services and their children.

PowerFlow only syncs business services that are aligned with devices that are already synced with ServiceNow. Before setting up business service sync, you must first sync devices between SL1 and ServiceNow.

To sync SL1 business services with ServiceNow:

In ServiceNow, create an identifier rule for syncing services by typing "CI Identifiers" in the filter navigator and clicking New on the Identifiers page:

Complete the following fields:

Name. Type a relevant name for this rule, such as "Business Service".
Applies to. Select cmdb_ci_service.
Independent. Select this option.

Right-click the gray header and click Save to save the record.
On the Identifier Entries tab, click New and add the relevant values from the Criterion attributes field for this business service, such as name, service_classification and correlation_id.
Click Submit.
Repeat steps 4-5 for each identifier you want to add.
Go to the Applications page of the PowerFlow user interface and run the "Cache ServiceNow Companies, CIs and SL1 Orgs, Device Classes" application. This application reads all existing SL1 Device Classes, Organizations, ServiceNow CIs, and Companies and writes them to a cache.
When that application completes, go to the Applications page and run the "Sync Devices from SL1 to ServiceNow" application to sync devices and their properties and relationships from SL1 to ServiceNow.
When that application completes, go to the Applications page and select the "Sync Business Services from SL1 to ServiceNow" application.
Click Configure () to open the Configuration pane:
Complete the following fields, as needed:

Configuration. Select the relevant configuration object to align with this application. You cannot edit fields that are populated by the configuration object. Required.

The region field is populated by the configuration object you aligned with this application. The region value must match the value in the SL1 Region field in ServiceNow. If you need to update this value, you will need to define the region variable in the configuration object that is aligned with this application, or align a different configuration object that has the correct region value.
read_timeout. Specify the maximum amount of time in seconds the application should wait for a response before timing out. The default is 20 seconds.
sl1_chunk_size. Specify the number of services to include in each chunk sent to ServiceNow when you run this application. The default chunk size is 500.
snow_request_limit. Specify the number of CIs fetched from ServiceNow in each request. The default is 500 objects per chunk.
sl1_url_override. Specify a URL that is different from the standard SL1 URL that gets sent to the ServiceNow CI record. Optional.
business_service_ci_class. Specify the ServiceNow CI Class for Business Services. The default is cmdb_ci_service.
it_service_ci_class. Specify the ServiceNow CI Class for IT Services. The default is cmdb_ci_service_technical.
business_service_classification, it_service_classification, and device_service_classification. Use these fields to update the default service classifications. Optional.
relationship_type. Specify the relationship type string to use between services. The default is Depends on::Used by.
discovery_source. Specify the ServiceNow Discovery source. The default is "Other Automated".
verify_snow_ssl. Toggle on (blue) this option to enable verification of the SSL certification when you run this application.
snow_batch_size. Specify the total number of CIs being sent to ServiceNow in each triggered application. The default is 150 objects per batch.
snow_chunk_size. Specify the number of CI objects to send in each chunk or in each sub-payload with a batch (specifed in the snow_batch_size field). The default is 150 objects per chunk or sub-payload.
retry_max. The maximum number of times PowerFlow will retry to execute the step before it stops retrying and logs a step failure. For example, if retry_max is 3, PowerFlow will retry after 1 second, then 2 seconds, then 4 seconds, and stop if the last retry fails. The default is 0.
retry_backoff_max.The maximum time interval for the retry_backoff option, in seconds. For example, if you have retry_max set to 15, the delays will be 1, 2, 4, 8, 16, 32, 64, 120, 240, 480, 600, 600, 600, 600, and 600. The default is 600.
Domain_Separation. Select this option if your ServiceNow environment is domain-separated, where the data, processes, and administrative tasks have been organized into logical groupings called domains. If your ServiceNow instance is domain-separated, the user listed in the snow_user field must be a member of the top domain and have access to all of the domains you intend to integrate. Also, ServiceNow should be the "source of truth" for organizations if your environment is domain-separated.
Simulation_Mode. Select this option if you want to perform a simulated run of this application to show you the potential results of that run.
company_mapping_override. In this section, you can create a new mapping for the ServiceNow "company" field for ServiceNow CIs (the first field on the left in the user interface). You can override the "company" field with a different ServiceNow field where you can read and write the company_sys_id for CIs.

Click Save. The Configuration pane automatically closes.
Click Run () to run the "Sync Business Services from SL1 to ServiceNow" application.

Syncing Business Services from ServiceNow to SL1

The Sync Business Services from ServiceNow to SL1 application syncs services that were defined in ServiceNow with Business Services in SL1. When you sync services from Service Now to SL1, PowerFlow recreates the service structure in SL1, where you can see the relationships between the service components, the application components, and the infrastructure components. You can also sync any asset fields on the service using an attribute mapping on the Configuration pane.

Aspects of Syncing Business Services from ServiceNow to SL1

This process syncs the business service structure or map from ServiceNow; however, because ServiceNow only allows one device service for each device, the process will not dynamically create rules and services in SL1.
This process groups all devices into a single device service. If there are other services at the same level as the devices, that service will be modeled as a separate aggregate service in SL1.
An aggregate service in SL1 will only be created with services as children and a device service in SL1 will only be created with devices as children.
Depending on the actions taken in ServiceNow, an aggregate service can be inserted above or a device service may be inserted below certain services when the aggregate service is created in SL1.
This process creates device services in SL1, but it does not create devices in SL1.
Services are not merged in this process, so when you use the "Sync Business Services from ServiceNow to SL1" application, the "source of truth" will be set to ServiceNow, not SL1.
If a ServiceNow service has no child services or child devices, that service will not be created in SL1.
If a ServiceNow service was previously synced to SL1 when it was not empty, but it is now an empty service ServiceNow, the service is deleted in SL1.

The following tables in ServiceNow are treated as services in a sync to SL1:

cmdb_ci_service
cmdb_ci_service_technical
cmdb_ci_query_based_service
cmdb_ci_service_discovered
cmdb_ci_service_auto
cmdb_ci_service_group
service_offering
cmdb_ci_service_manual
cmdb_ci_service_calculated

All other tables will be treated as devices.

The cmdb_ci_query_based_service table contains the device services within ServiceNow. For any other service with a CI as a direct child, a device service will be inserted in between this service and the child CI in SL1.

Syncing services from ServiceNow to SL1 requires SL1 10.2.0 or later.

To sync ServiceNow services with SL1 Business Services:

In ServiceNow, configure your business service structure or map so it is ready to by synced to SL1:
For each service that you want to sync with SL1:
- Ensure that the SL1 Region field in ServiceNow matches the region field in PowerFlow.
- Set the SL1 Monitored flag to True.
Go to the Applications page of the PowerFlow user interface and run the "Cache ServiceNow Companies, CIs and SL1 Orgs, Device Classes" application. This application reads all existing SL1 Device Classes, Organizations, ServiceNow CIs, and Companies and writes them to a cache.
When that application completes, go to the Applications page and run the "Sync Devices from SL1 to ServiceNow" application to enable PowerFlow to use the mappings and additional attribute options from Device Sync.
When that application completes, go to the Applications page and select the "Sync Business Services from ServiceNow to SL1" application.
Click Configure () to open the Configuration pane:
Complete the following fields, as needed:
- Configuration. Select the relevant configuration object to align with this application. You cannot edit fields that are populated by the configuration object. Required.
  
  The region field is populated by the configuration object you aligned with this application. The region value must match the value in the SL1 Region field in ServiceNow. If you need to update this value, you will need to define the region variable in the configuration object that is aligned with this application, or align a different configuration object that has the correct region value.
- read_timeout. Specify the maximum amount of time in seconds the application should wait for a response before timing out. The default is 20 seconds.
- verify_snow_ssl. Toggle on (blue) this option to enable verification of the SSL certification when you run this application.
- attribute_map. In this section, click Add Mapping if you want to create a mapping for any other asset fields that you want to sync between SL1 (the first column) and ServiceNow (the second column).
- company_mapping_override. In this section, you can create a new mapping for the ServiceNow "company" field for ServiceNow CIs (the first field on the left in the user interface). You can override the "company" field with a different ServiceNow field where you can read and write the company_sys_id for CIs.
Click Save. The Configuration pane automatically closes.
Click Run () to run the application. When the application completes, the ServiceNow business services will be available on the Business Services page of SL1:

Syncing Installed Software between SL1 and ServiceNow

You can use the following applications to sync your installed software assets between and ServiceNow:

"Sync Software Packages from SL1 to ServiceNow". Reads all software packages from SL1 and creates new CIs in ServiceNow. Run this application before running the "Sync Installed Software" application.
"Sync Installed Software from SL1 to ServiceNow". Reads all available software packages from SL1 and the devices aligned to that software by region and syncs them with ServiceNow.

The applications do not currently support domain separation.

The Software Asset Management (SAM) application in ServiceNow is not supported with the current level of installed software data acquired with SL1. As a result, syncing installed software data with ServiceNow Discovery and other Software Asset Management software is not currently supported.

To sync installed software between SL1 and ServiceNow:

Make sure that you have recently run the "Sync Devices from SL1 to ServiceNow" application to populate the device cache.
In the PowerFlow user interface, go to the Applications page and select the "Sync Software Packages from SL1 to ServiceNow" application.

Click Configure () to open the Configuration pane:

Complete the following fields, as needed:

Configuration. Select the relevant configuration object to align with this application. You cannot edit fields that are populated by the configuration object. Required.

The region field is populated by the configuration object you aligned with this application. The region value must match the value in the SL1 Region field in ServiceNow. If you need to update this value, you will need to define the region variable in the configuration object that is aligned with this application, or align a different configuration object that has the correct region value.
read_timeout. Specify the maximum amount of time in seconds the application should wait for a response before timing out. The default is 20 seconds.
snow_request_limit. Specify the number of objects fetched from ServiceNow in each request. The default is 500 objects per chunk.
snow_chunk_size. Specify the number of objects to send in each chunk. The default is 150 objects per chunk.
verify_snow_ssl. Toggle on (blue) this option to enable verification of the SSL certification when you run this application.

Click Save and wait for the "App & Config modifications saved" pop-up message to appear. The Configuration pane automatically closes after this message appears.
Click Run () to run the application.
After the "Sync Software Packages from SL1 to ServiceNow" application finishes running, go to the Applications page and select the "Sync Installed Software from SL1 to ServiceNow" application.
Click Configure () to open the Configuration pane:

Complete the following fields, as needed:

Configuration. Select the relevant configuration object to align with this application. You cannot edit fields that are populated by the configuration object. Required.
region. The region value is populated by the configuration object you selected. The region value must match the value in the SL_Region field in ServiceNow. If you need to update this value, you will need to define the region variable in the configuration that is aligned with this application, or align a different configuration that has the correct region value.
chunk_size. Specify the number of services to include in each chunk sent to ServiceNow when you run this application. The default chunk size is 500.
read_timeout. Specify the maximum amount of time in seconds the application should wait for a response before timing out. The default is 20 seconds.

Click Save and wait for the "App & Config modifications saved" pop-up message to appear. The Configuration pane automatically closes after this message appears.
Click Run () to run the application.

Discovery Sync

The Discovery Sync integration lets you use SL1 for discovering and syncing ServiceNow devices. With Discovery Sync, you start an SL1 discovery session from ServiceNow and then sync the newly discovered SL1 devices or virtual devices and their data with ServiceNow.

Before running a Discovery Sync session, you must complete the following steps first:

For domain-separated ServiceNow instances, perform a company sync by running the "Sync Organizations from SL1 to ServiceNow" application in the PowerFlow user interface. For more information, see Syncing Organizations from SL1 to ServiceNow.
In ServiceNow, configure a service request for Discovery Sync. For more information, see Configuring a ServiceNow Service Request for Discovery Sync.
In the PowerFlow user interface, run the applications listed in the Discovery Sync Workflow.

Configuring a ServiceNow Service Request for Discovery Sync

Before you can run a Discovery Sync, you need to configure the catalog and category values in the ServiceNow service request forms. You also need to activate the "Device Discovery" service request in ServiceNow.

NOTE: Because some of the fields in the service request form will only populate if you have completed the previous fields in the form, you need to complete the fields in the service request form in sequential order.

To configure the ServiceNow service requests for Discovery Sync:

In ServiceNow, search for "Maintain Items" in the filter navigator.
Go to Service Catalog > Catalog Definitions > Maintain Items and type "ScienceLogic" in the Category field. The Device Discovery and Monitoring Removal service requests appear:

Open the Device Discovery service request and ensure that the Catalogs and Category fields are accurate. For example:

NOTE: Do not set the Category to a Change Request.

If you need to update these fields, click the "To edit this record click here" link at the top of the detail page.
Update the fields and click the Update button to save your changes.
From the Catalog Items page, click the check box for the Device Discovery service request and click Activate.

NOTE: This service request is instance-specific, which means that the service request will appear in the same location as the catalogs you specified for that request. In the example, above, the Catalog was set to Service Catalog.

Navigate to the relevant catalog for the service request. For example, if you selected Service Catalog for one or both requests, then type "Service Catalog" in the filter navigator, or select Self-Service > Service Catalog to view the new service requests. Type "device discovery" in the Search catalog field to quickly locate the request.
Run the applications listed in the Discovery Sync Workflow before creating the Device Discovery service request in ServiceNow.

Discovery Sync Workflow

To prepare SL1 and ServiceNow for a Discovery Sync, run the following applications in the PowerFlow user interface, in the following order:

Sync Discovery Requirements. This application exports information from SL1 to populate the information in the ServiceNow request form. You must run this application before you can create the discovery sync session in ServiceNow. This application uses one or more of the following options from the Configuration pane:

Configuration. Select the relevant configuration object to align with this application. You cannot edit fields that are populated by the configuration object. Required.

The region field is populated by the configuration object you aligned with this application. The region value must match the value in the SL1 Region field in ServiceNow. If you need to update this value, you will need to define the region variable in the configuration object that is aligned with this application, or align a different configuration object that has the correct region value.
read_timeout. Specify the maximum amount of time in seconds the application should wait for a response before timing out. The default is 30 seconds.
sl1_chunk_size. Specify the number of object to include in each chunk sent from SL1 to ServiceNow. The default is 500.
snow_chunk_size. Specify the number of objects to send in each chunk from ServiceNow. The default is 150 objects per chunk.
Create_Missing. Select this option if you want PowerFlow to create a new device or CI if that record is missing, based on your selection in the Source_of_Truth field.
Sync_Empty_Groups. Select this option if you want to sync device groups that have no devices, or device groups that have devices but no matching CIs.
Source_of_Truth. Select whether you want to use data from ServiceNow or ScienceLogic as the "source of truth" when this application encounters duplicate data or data collisions.
attribute_mappings. In this section, you can create a mapping for any other custom attributes you want to sync between SL1 (the first column) and ServiceNow (the second column).

Sync Service Requests from ServiceNow to SL1. This application sends the request forms to SL1. This application was called "Sync Discovery Session Requests from ServiceNow to SL1" in previous versions of the SyncPack. This application uses one or more of the following options from the Configuration pane:

Configuration. Select the relevant configuration object to align with this application. You cannot edit fields that are populated by the configuration object. Required.
read_timeout. Specify the maximum amount of time in seconds the application should wait for a response before timing out. The default is 20 seconds.
Open_State. The State ID from ServiceNow that specifies which Requested Items (RITMs) to pull and process. The default is 1.
Closed_Success_State. The State ID for a successfully created virtual device. The State ID for a successful run changes from 1 to 2 and then ends with 4. The default is 3.
Closed_Failed_State. The State ID for failed discoveries or failed virtual device creation, usually caused by invalid payloads. The State ID for a failed run changes from 1 to 2 and then ends with 4. The default is 4.
In_Progress_State. The State ID for RITMs for a running discovery. The default is 2.
target_vcug. Leave this field blank.
recursively_disable_children. Leave this field blank.

Sync Discovery Session Status from SL1 to ServiceNow. This application populates the discovery session logs back to ServiceNow. This application uses the following options from the Configuration pane:

Configuration. Select the relevant configuration object to align with this application. You cannot edit fields that are populated by the configuration object. Required.
read_timeout. Specify the maximum amount of time in seconds the application should wait for a response before timing out. The default is 20 seconds.
retry_max. The maximum number of times PowerFlow will retry to execute the step before it stops retrying and logs a step failure. For example, if retry_max is 3, PowerFlow will retry after 1 second, then 2 seconds, then 4 seconds, and stop if the last retry fails. The default is 0.
retry_backoff_max.The maximum time interval for the retry_backoff option, in seconds. For example, if you have retry_max set to 15, the delays will be 1, 2, 4, 8, 16, 32, 64, 120, 240, 480, 600, 600, 600, 600, and 600. The default is 600.
Closed_Success_State. The State ID for a successfully created discovery. The State ID for a successful run changes from 1 to 2 and then ends with 4. The default is 3.
Closed_Failed_State. The State ID for failed discoveries, usually caused by invalid payloads. The State ID for a failed run changes from 1 to 2 and then ends with 4. The default is 4.
sys_id_target. Takes the sys_id value from the CI in the ServiceNow Service Request and populates it in the relevant field in SL1, such as c-sys_id.
ci_class_target. Takes the ci_class value from the CI in the ServiceNow Service Request and populates it in the relevant field in SL1, such as c-ci_class_target.

If the sys_id_target field and the ci_class_target field are not populated, PowerFlow will skip the process of consuming cached data and populating custom attribute fields in SL1 with the sys_id and ci_class values of newly discovered devices.
snow_attributes_created. Select this option if custom attributes for ServiceNow sys_id and ci_class already exist in SL1.

Sync Discovery Templates from SL1 to ServiceNow. This application creates Service Catalog templates in ServiceNow based on Discovery Sessions that were created in SL1. This option lets you use any existing SL1 Discovery Sessions as a template for discovering or monitoring a CI with SL1. This application uses the following options from the Configuration pane:

Configuration. Select the relevant configuration object to align with this application. You cannot edit fields that are populated by the configuration object. Required.
chunk_size. Specify the number of devices to include in each chunk sent to ServiceNow when you run this application. The default is 0.
template_prefix. Specify the prefix string that PowerFlow will search for in SL1. Any Discovery Sessions that contain that string will be used in ServiceNow to create a service catalog template. The default string is ServiceNow Template:, but you can configure this as needed.
read_timeout. Specify the maximum amount of time in seconds the application should wait for a response before timing out. The default is 30 seconds.

In SL1, go to the Discovery Control Panel page (Manage > Classic Discovery) and search for the Discovery Session or Sessions that you want to use as a template. The start of the name in the Name field should match the value in the template_prefix field, above:

Sync Devices from SL1 to ServiceNow. Running this application ensures that the devices discovered by SL1 get synced to ServiceNow.
When the applications finish running, PowerFlow sends the status of those applications to ServiceNow, and you can run a Discovery Sync in ServiceNow.

Running a Discovery Sync in ServiceNow

The Discovery Sync process starts an SL1 discovery session from ServiceNow and syncs the newly discovered SL1 devices and their data with ServiceNow. You can choose to discover standard devices or virtual devices.

To run a Discovery Sync from the Service Catalog page:

In ServiceNow, search for "service catalog" in the filter navigator.
Navigate to the Service Catalog page (Self-Service > Service Catalog), type "device discovery" in the Search catalog field at the top right, and press Enter. The Device Discovery catalog entry appears:

NOTE: Previous versions of the "ScienceLogic SL1: CMDB & Incident Automation Application" (also called the Certified or Scoped Application) created two separate service requests: Create Virtual Device and Device Discovery. Both features have been combined into the Device Discovery service request.

Click Device Discovery. The Device Discovery service request appears:

In the What company is this for? field, specify the company. The Region field updates automatically based on the company you select.
In the Request Type field, select Discover Device(s) or Create Virtual Device, depending on the type of device you want to discover.

If you selected Discover Device(s), go to step 6.
If you selected Create Virtual Device, go to step 7.

If you selected Discover Device(s) in the Request Type field, complete the following fields:

Log All. Select this option if you want the discovery session to use verbose logging. When you select this option, SL1 logs details about each IP address or hostname specified in the IP Address/Hostname Discovery List field, even if the results are "No device found at this address."
Select Template. To use a template that contains your device discovery information, select the template from the drop-down.

You can save the current device discovery as a template by checking Save as Template. A template saves all of the discovery settings except for the IP addresses. You can access existing templates on the Catalog Template page in ServiceNow (ScienceLogic > Automations > Catalog Templates).

IP Address/Hostname Discovery List. Provide a list of IP addresses, hostnames, or fully-qualified domain names for SL1 to scan during discovery:

One or more single IPv4 addresses separated by commas and a new line. Each IP address must be in standard IP notation and cannot exceed 15 characters. For example, "10.20.30.1, 10.20.30.2, 10.20."
One or more ranges of IPv4 addresses with "-" (dash) characters between the beginning of the range and the end of the range. Separate each range with a comma. For example, "10.20.30.1 – 10.20.30.254".
One or more IP address ranges in IPv4 CIDR notation. Separate each item in the list with a comma. For example, "192.168.168.0/24".
One or more hostnames (fully-qualified domain names). Separate each item in the list with a comma.

Credentials. Select one or more SNMP credentials to allow SL1 to access a device's SNMP data.
Discover Non-SNMP. Specifies whether or not SL1 should discover devices that don't respond to SNMP requests.
Model Devices. Determines whether or not the devices that are discovered with this discovery session can be managed through SL1.
DHCP. Specifies whether or not the specified range of IPs and hostnames use DHCP. If you select this option, SL1 performs a DNS lookup for the device during discovery and each time SL1 retrieves information from the device.
Device Model Cache TTL (h). Amount of time, in hours, that SL1 stores information about devices that are discovered but not modeled, either because the Model Devices option is not enabled or because SL1 cannot determine whether a duplicate device already exists. The cached data can be used to manually model the device from the Discovery Session window.
Collection Server. Select an existing collector to monitor the discovered devices. Required.
What company is this for?. Specify the company that will use this discovery data. Click the magnifying glass icon to locate a company.
Add Devices to Device Groups. Select one or more existing device groups to which you want to add the discovered devices.
Apply Device Template . Select an existing device template if needed. As SL1 discovers a device in the IP discovery list, that device is configured with the selected device template.
Initial Scan Level. For this discovery session only, specifies the data to be gathered during the initial discovery session.
Scan Throttle. Specifies the amount of time a discovery process should pause between each specified IP address (specified in the IP Address/Hostname Discovery List field). Pausing discovery processes between IP addresses spreads the amount of network traffic generated by discovery over a longer period of time.
Scan Default Ports. Select this option to scan the default ports: 21,22,23,25,80. If you de-select this option, you can specify a different list of ports in the Custom Port Scan field that appears.
Port Scan All IPs. For the initial discovery session only, specifies whether SL1 should scan all IP addresses on a device for open ports.
Port Scan Timeout. For the initial discovery session only, specifies the length of time, in milliseconds, after which SL1 should stop trying to scan an IP address for open ports and begin scanning the next IP address (if applicable).
Interface Inventory Timeout (ms). Specifies the maximum amount of time that the discovery processes will spend polling a device for the list of interfaces. After the specified time, SL1 will stop polling the device, will not model the device, and will continue with discovery. The default value is 600,000 ms (10 minutes).
Maximum Allowed Interfaces. Specifies the maximum number of interfaces per devices. If a device exceeds this number of interfaces, SL1 stops scanning the device, will not model the device, and will continue with discovery. The default value is 10,000.
Bypass Interface Inventory. Select this option if you do not want SL1 to attempt to discover interfaces for each device in the discovery session.

If you selected Create Virtual Device in the Request Type field, complete the following fields:

Name. Type a name for the virtual device.
Virtual Device Class. Specify the device class of the virtual device. Click the magnifying glass icon to locate any classes aligned with your organization.
Collector Group. Specify the SL1 collector group to use for the Discovery Sync. Click the magnifying glass icon to locate any collector groups aligned with your organization.

Click Order Now. On the Order Status page that appears, make a note of value in the Request Number field:

In the PowerFlow user interface, go to the Applications page and run the "Sync Service Requests from ServiceNow to SL1" application.
When the application completes, go to Self-Service > My Requests in ServiceNow.
Click the RITM record link to go to the Requested Item page. The State field should update to Closed Complete and the request should be assigned to itself.
In the PowerFlow user interface, go to the Applications page and run the "Sync Devices from SL1 to ServiceNow" application to make sure that the device or devices were discovered.
For a standard device discovery, go to ServiceNow and perform the following:

Scroll down to the Activities pane to verify that you have a comment stating the discovery completed.
In SL1, navigate to the Discovery Control Panel page (Registry > Manage > Discovery) and verify that SL1 created a new discovery session with that ID.

For a virtual device discovery, go to ServiceNow and perform the following:

Scroll down to the Activities pane to verify that you have a comment stating "Virtual Device <name> Created with SLID: <new id>":

In SL1, navigate to the Device Manager page (Registry > Device Manager) and verify that SL1 created a new device with that device ID.

Discovering One or More Devices from ServiceNow to SL1

If you want to quickly select one or more CIs in ServiceNow for monitoring in SL1, you can use the Monitor Device List option from the Configuration Items list view, or the Monitor Device option from the Configuration Item detail view.

This feature uses registered events in ServiceNow that are queued to ServiceNow Event Management to trigger actions in PowerFlow. Also, this method is just an example of one of many ways to trigger a registered event. For more information about registered events, including examples of other triggering events you can define in ServiceNow, see the ServiceNow Registered Events appendix.

You will need to create a discovery template for a discovery process created on the Service Catalog page before you can discover devices using that template on the Configuration Items page. A template saves all of the discovery settings except for the IP addresses. You can access existing templates on the Catalog Template page in ServiceNow (ScienceLogic > Automations > Catalog Templates).

To discover one or more devices from ServiceNow:

In ServiceNow, navigate to the Configuration Items page.
From the list view, select the CI or CIs (devices) that you want to discover.

A CI in ServiceNow must be aligned with a company in ServiceNow, or the service request will be canceled. Also, that company must be associated with a ScienceLogic Region.

Right-click anywhere in the window and select Monitor Device List from the pop-up menu. A Select Discovery Template dialog box appears.

You can also select a specific CI from the list view and click the Monitor Device option from the Configuration Item detail view. You will also need to use an existing template for this process.

Select a discovery template to use for the current discovery.
Click OK to use the template. ServiceNow generates a new service request for Device Discovery for each CI.

In the PowerFlow user interface, select the "Sync Service Requests from ServiceNow to SL1" application from the Applications page and click Configure (). The Configuration pane appears:

Complete the following fields, as needed:

Configuration. Select the relevant configuration object to align with this application. You cannot edit fields that are populated by the configuration object. Required.
read_timeout. Specify the maximum amount of time in seconds the application should wait for a response before timing out. The default is 20 seconds.
Open_State. The State ID from ServiceNow that specifies which Requested Items (RITMs) to pull and process. The default is 1.
Closed_Success_State. The State ID for a successfully created virtual device. The State ID for a successful run changes from 1 to 2 and then ends with 4. The default is 3.
Closed_Failed_State The State ID for failed discoveries or failed virtual device creation, usually caused by invalid payloads. The State ID for a failed run changes from 1 to 2 and then ends with 4. The default is 4.
In_Progress_State. The State ID for RITMs for a running discovery. The default is 2.
target_vcug. Leave this field blank.
verify_snow_ssl. Toggle on (blue) this option to enable verification of the SSL certification when you run this application.
recursively_disable_children. Leave this field blank.

Click Save. The Configuration pane automatically closes.
Click Run () to run the application.
Go to the Applications page and run the "Sync Devices from SL1 to ServiceNow" application to make sure that the device or devices were discovered.

Decommissioning Devices

If you want to quickly select one or more CIs in ServiceNow for to remove from monitoring (or "decommission") in SL1, you can use the Device Monitoring Removal list option from the Configuration Items list view, or the Monitoring Removal option from the Configuration Item detail view.

You then use the "Sync Service Requests from ServiceNow to SL1" application to decommission the devices that you no longer want to monitor. Running this application takes the list of synced devices in the service request and moves them to an SL1 Virtual Collector Group (VCUG). The "Sync Service Requests from ServiceNow to SL1" application was formerly named "Sync Discovery Session Requests from ServiceNow to SL1".

If you move a parent device to a new VCUG, then all of its children move as well. If you move a child directly, only the child moves.

Activating the ServiceNow Service Request for Monitoring Removal

To activate the ServiceNow service request for Device Decommission:

In ServiceNow, search for "Maintain Items" in the filter navigator.
Go to Service Catalog > Catalog Definitions > Maintain Items and type "ScienceLogic" in the Category field.

Open the "Monitoring Removal" service request and ensure that the Catalogs and Category fields are complete. Add the relevant information if the fields are blank. For example:

NOTE: Do not set the Category to a Change Request.

If you need to update these fields, click the "To edit this record click here" link at the top of the detail page.
Update the fields and click the Update button to save your changes.
From the Catalog Items page, click the check box for the Monitoring Removal service request and click the Activate button at the bottom of the Catalog Items window.
Navigate to the relevant catalog for the service request. For example, if you selected Service Catalog, then type "Service Catalog" in the filter navigator, or select Self-Service > Service Catalog to view the new service requests.

Removing Devices from Monitoring

To decommission Configuration Items (devices) in ServiceNow that you no longer want to monitor:

In ServiceNow, navigate to the Configuration Items window.
From the list view, select the CI or CIs (devices) that you want to decommission.

A CI in ServiceNow must be aligned with a company in ServiceNow, or the service request will be canceled. Also, a company must be associated with a ScienceLogic Region.

Right-click anywhere on the window and select Device Monitoring Removal list from the pop-up menu. A dialog box appears.
Click OK to remove the CI or CIs from monitoring. ServiceNow generates a new service request for Monitoring Removal for each CI.

You can also select a specific CI from the list view and click the Monitoring Removal option from the Configuration Item detail view.
In the PowerFlow user interface, select the "Sync Service Requests from ServiceNow to SL1" application from the Applications page and click Configure () on the application detail page. The Configuration pane appears:
Complete the following fields:

Configuration. Select the relevant configuration object to align with this application. You cannot edit fields that are populated by the configuration object. Required.
read_timeout. Specify the maximum amount of time in seconds the application should wait for a response before timing out. The default is 20 seconds.
recursively_disable_children. Check this option to move all child devices of the devices you are decommissioning to the VCUG. If this option is not checked and a parent device is in the disable request, the parent device will be skipped with a warning message.
target_vcug. Specify the ID of the SL1 Virtual Collection Group (VCUG) you created to hold the devices on the Collector Group Settings page (System > Settings > Collector Groups). If this value is null, the application will attempt to pull the value from the target_vcug field in the "Delete Devices from SL1" application.

Click Save and wait for the "App & Config modifications saved" pop-up message to appear. The Configuration pane automatically closes after this message appears.
Click Run () to run the application.

Deleting Devices

The "Delete Devices from SL1" application lets you delete devices in a specific Virtual Collector Group (VCUG) if those devices have not been modified in SL1 for a specified time, such as one day or five days. You can update this time in the max_age configuration value, which is described below.

To delete devices from an SL1 Virtual Collector Group:

In the PowerFlow user interface, run the "Sync Service Requests from ServiceNow to SL1" application to pull a list of decommissioned devices that you no longer want to monitor. For more information, see Decommissioning Devices.
On the Applications page, select the "Delete Devices from SL1" application and click Configure () on the application detail page. The Configuration page appears:

Complete the following fields, as needed:

Configuration. Select the relevant configuration object to align with this application. You cannot edit fields that are populated by the configuration object. Required.
read_timeout. Specify the maximum amount of time in seconds the application should wait for a response before timing out. The default is 20 seconds.
max_age. Specify how long (in days) that you want to keep the devices in the VCUG before deleting the devices. The default is 0 days. If this setting is 0, all devices in the VCUG will be deleted as soon as this application runs. If this setting is null, the application will fail. If all device children are in the same VCUG, the application will delete the target device and all of its children.
target_vcug. Specify the ID of the SL1 Virtual Collection Group (VCUG) you created to hold the devices on the Collector Group Settings page (System > Settings > Collector Groups). Set this value to -1 if you want this applications to use the target_vcug value from the "Sync Service Requests from ServiceNow to SL1" application.

If you specify a value to target_vcug here, the "Delete Devices from SL1" application will use that value instead of the target_vcug value from the "Sync Service Requests from ServiceNow to SL1" application.

Click Save. The Configuration pane automatically closes.
Click Run () to run the application.

Scheduling PowerFlow Applications

Using the PowerFlow user interface, you can configure PowerFlow applications to run on a schedule instead of manually running the applications. As a best practice, if you use any of these applications, ScienceLogic recommends that you schedule those applications, in the following order:

"Cache ServiceNow CIs and SL1 Device Classes"
"Sync Devices from SL1 to ServiceNow"
"Sync Interfaces from SL1 to ServiceNow"

ScienceLogic recommends that you schedule these applications to run at least every 23 hours. You can also schedule additional applications as needed.

You can create one or more schedules for a single application in the PowerFlow user interface. When creating each schedule, you can specify the queue and the configuration file for that application.

To schedule an application:

On the Applications page (), click the Schedule button for the application you want to schedule. The Schedule window appears, displaying any existing schedules for that application:

If you set up a schedule using a cron expression, the details of that schedule display in a more readable format in this list. For example, if you set up a cron expression of */4 * * * *, the schedule on this window includes the cron expression along with an explanation of that expression: "Every 0, 4, 8, 12, 16, 20, 24, 28, 32, 36, 40, 44, 48, 52, and 56th minute past every hour".

Select a schedule from the list to view the details for that schedule.
Click the + icon to create a schedule. A blank Schedule window appears:

In the Schedule window, complete the following fields:

Schedule Name. Type a name for the schedule.
Switch to. Use this toggle to switch between a cron expression and setting the frequency in seconds.

Cron expression. Select this option to schedule the application using a cron expression. If you select this option, you can create complicated schedules based on minutes, hours, the day of the month, the month, and the day of the week. As you update the cron expression, the Schedule window displays the results of the expression in more readable language, such as Expression: "Every 0 and 30th minute past every hour on the 1 and 31st of every month", based on */30 * * /30 * *.
Frequency in seconds. Type the number of seconds per interval that you want to run the application.

Custom Parameters. Type any JSON parameters you want to use for this schedule, such as information about a configuration file or mappings.

Click Save Schedule. The schedule is added to the list of schedules on the initial Schedule window. Also, on the Applications page, the word "Scheduled" appears in the Scheduled column for this application, and the Schedule button contains a check mark:

After you create a schedule, it continues to run until you delete it. Also, you cannot edit an existing schedule, but you can delete it and create a similar schedule if needed.

To view or delete an existing schedule:

On the Applications page, click the Schedule button for the application that contains a schedule you want to delete. The Schedule window appears.

Click the down arrow icon () to view the details of an existing schedule:

To delete the selected schedule, click Delete.

The following image shows how you can schedule PowerFlow applications for multiple ServiceNow domains:

Log Messages for the "Generate Required CI Relations for ServiceNow" Application

This section describes the different types of log messages you might see in the Step Log when you run the "Generate Required CI Relations for ServiceNow" application. Please note that this application is a report used by PowerFlow, and it does not send any data to ServiceNow.

The following message displays if there are devices in a device tree that do not currently have a CI class mapping assigned.

Warning: 2751 Relations with missing mappings detected. Please re-run app with log level 10 to troubleshoot.

In this situation, the device tree cannot be built in ServiceNow. To address this issue, make sure that you have your entire technology tree mapped out in the mappings section of the "Sync Devices from SL1 to ServiceNow" application or in the mappings section of the "Generate Required CI Relations for ServiceNow" application.

If you do a Custom Run of the "Generate Required CI Relations for ServiceNow" application in Debug mode (log level 10), the application will create a log that displays the parent and child class, CI, and device ID. For example:

Debug: Missing Mapping for Device. Parent: {"class": "VMware | Cluster", "ci": None, "id": 76}, Child: {"class": "VMware | Host Server", ci: "cmdb_ci_esx_server", id: 363 }

The following message appears if the GraphQL payloads had bad data for parent and or child devices:

Warning: 10 bad payloads received from SL1. Re-run app in debug to troubleshoot.

If you do a Custom Run the application in Debug mode, the application will create a log that displays these payloads.

The following message appears if all relations are mapped:

Flow: No missing relations found!

The following message appears if there is a parent/child relation between ServiceNow CI classes that does not currently exist in ServiceNow and is required to sync those devices:

Flow: Missing Relations: [{"parent": "cmdb_ci_vcenter_folder", "child": "cmdb_ci_esx_server"}, {"parent": "cmdb_ci_vcenter", "child": "cmdb_ci_vcenter_datacenter"}]

Refer to the labels in the log (above) to determine which CI class is the parent type and which is the child type. To address this issue, navigate to your ServiceNow instance and create the required service rules based on the recommendations in the Step Log.

The following message appears if the application encounters a list of relations that are required, but were successfully found in ServiceNow:

Info: Found Relations: [{"parent": "cmdb_ci_vcenter_folder", "child": "cmdb_ci_esx_server"}, {"parent": "cmdb_ci_vcenter", "child": "cmdb_ci_vcenter_datacenter"}]

This message lets you verify that your mappings and relations are configured correctly.