Configuring Additional Syncs for the CMDB SyncPack

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

For more information about Organization and Device Sync, see Configuring Organization Sync and Device Sync for the CMDB SyncPack.

For more information about using configuration objects with this SyncPack, see Creating and Aligning a Configuration Object.

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.

In the Company Mapping Override section, you can create a new mapping for the ServiceNow company field. 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, and the device services created in SL1 as the result of the sync can contain multiple devices.
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).
In the Company Mapping Override section, you can create a new mapping for the ServiceNow company field. 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 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"}}

In the Mappings section, click the Edit button (PowerFlow 2.7.0 or later) or the expand button () to view and edit the mappings between ServiceNow CI classes and SL1 device classes. You can map a single ServiceNow CI class with multiple SL1 device classes.

If no mappings are provided in this section, the application 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.

For more information about how to view, edit, and create mappings, see Editing Mappings in a PowerFlow Application. This topic also covers how to use the Company Mapping Override and the Attribute Mappings sections, below.
In the Company Mapping Override section, you can create a new mapping for the ServiceNow company field. 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 Edit button (PowerFlow 2.7.0 or later) or the expand button () to view and edit mappings for any other custom attributes you want to sync between SL1 (the first column) and ServiceNow (the second column). For more information, including lists of default and available device attribute mappings, see Device Attribute Mappings.

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.

For the Attribute Mappings section, 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.

When an attribute value is "0" in SL1, the corresponding field in ServiceNow might display as empty.
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.

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.

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, go to the Catalog Items page (Service Catalog > Catalog Definitions > Maintain Items).
Type "ScienceLogic" in the Category column. The Device Discovery and Monitoring Removal service requests appear in the search results.
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 Edit in Catalog Builder button 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 the Activate button at the bottom of the Catalog Items window.

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.
Update_Name. This option addresses the situation where PowerFlow finds a match with a device or CI, but the names do not match. This option updates a device or CI 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 device name from ScienceLogic as the updated name.
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.
In the Company Mapping Override section, you can create a new mapping for the ServiceNow company field. You can override the company field with a different ServiceNow field where you can read and write the company_sys_id for CIs.

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.
retry_jitter. When selected, instead of using a defined interval between retries, the PowerFlow system will retry the step execution at random intervals. By default, this option is not selected.
retry_backoff. When selected, instead of using a defined interval between retries, PowerFlow will incrementally increase the interval between retries. By default, this option is not selected.
verify_snow_ssl. Toggle on (blue) this option to enable verification of the SSL certification when you run this application.

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. In SL1, go to the Discovery Sessions page (Devices > Discovery Sessions) 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.
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.

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, go 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.

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, go to the Catalog Items page (Service Catalog > Catalog Definitions > Maintain Items).
Type "ScienceLogic" in the Category column. The Device Discovery and Monitoring Removal service requests appear in the search results.
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. 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, go 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. 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.

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. File systems with parent CIs that have 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.
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.
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.
retry_jitter. When selected, instead of using a defined interval between retries, the PowerFlow system will retry the step execution at random intervals. By default, this option is not selected.
retry_backoff. When selected, instead of using a defined interval between retries, PowerFlow will incrementally increase the interval between retries. By default, this option is not selected.

In the Company Mapping Override section, you can create a new mapping for the ServiceNow company field. 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 Edit button (PowerFlow 2.7.0 or later) or the expand button () to view and edit the mappings for any other custom device attributes you want to sync between SL1 (the first column) and ServiceNow (the second column).

When an attribute value is "0" in SL1, the corresponding field in ServiceNow might display as empty.
Click Save. The Configuration pane closes.
Click Run to run the application.

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.

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

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.

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.
max_count_for_relationships. Specify the maximum number of device IDs to query for sets of relationships in a single chunk from SL1.
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.
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.
enable_advanced_topology. Select this option to allow the pull and process advanced topology step to be executed when the sync is run. If disabled, this step will be skipped. This toggle defaults to a value of True.
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.
retry_jitter. When selected, instead of using a defined interval between retries, the PowerFlow system will retry the step execution at random intervals. By default, this option is not selected.
retry_backoff. When selected, instead of using a defined interval between retries, PowerFlow will incrementally increase the interval between retries. By default, this option is not selected.
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.

In the Mappings section, click the Edit button (PowerFlow 2.7.0 or later) or the expand button () to view and edit the mappings between specific SL1 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.

For more information about how to view, edit, and create mappings, see Editing Mappings in a PowerFlow Application. This topic also covers how to use the Company Mapping Override and the Attribute Mappings sections, below.
In the Company Mapping Override section, you can create a new mapping for the ServiceNow company field. 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 Edit button to view and edit the mappings for any other custom device attributes you want to sync between SL1 (the first column) and ServiceNow (the second column).

When an attribute value is "0" in SL1, the corresponding field in ServiceNow might display as empty.
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.
You can add additional columns to this page using the Update Personalized List button () to add columns like Operational status, which is synced from SL1. The Operational status value is different from the SL1 Monitored value, but PowerFlow tracks both values.
Select a network interface from the list tab to see more information about the interface.

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. The values in this field will override any application variables that exist in the PowerFlow application you are scheduling.

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.

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.

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.