Frequently Asked Questions

No. While the ServiceNow store will list SAM Core as a requirement, along with SAM Foundation, the Flexera One app only needs one plugin or the other and not both. Software Asset Management (SAM) Foundation is the only plugin needed related to SAM.

Question: Is there a licensing cost associated with Software Asset Management (SAM) Foundation?

No. Software Asset Management Foundation is a free plugin but needs to be requested from ServiceNow’s Now Support (HI) portal to be installed.

Question: Why is this integration creating a “normalized” software installation record instead of updating the existing record?

This is necessary for a few different reasons:

•

There are often already duplicate software installation records in cases where multiple sources are involved. If we update both records, then you would end up with duplicate “normalized” installations that would only confuse things more.

•

If we use the same primary key values that ServiceNow uses for software installations as primary key values for “normalized installations,” the result will not match to any existing records. By default, without modifying standard behavior, this approach would create a new record.

•

If we update an existing software installation, the primary key value ServiceNow uses for the software installation would not match the value of the record that’s been normalized. The result would be that the original discovery source would create another record.

While there’s no perfect solution, with this approach you can at least filter the software installations to see only your normalized software estate, free of duplicates, by setting the filter to technopedia_id != NULL or software model categories includes FlexeraOne. This is the recommended approach for views, dashboards, and reporting.

Question: Why does this integration create a “normalized” model instead of updating the existing model?

This is necessary for multiple reasons:

•

Often in “discovery” models you will end up with duplicates, often several even, for what is the same actual model. If we update just one, it would cause more harm than good. If we updated all, you’d have duplicate models.

•

Typically models coalesce using the “name” value. This value will not be the same if we update the model, and the discovery source will likely create another record. This also makes attempting to update a model after it is normalized very difficult.

•

Flexera lifecycle records are associated to a “normalized” Technopedia record. In order to add the lifecycle records we have to also add the model record they relate to.

The recommended approach, if the discovery source is not Flexera but a source being fed into ServiceNow directly, is to allow the integration to update the hardware records as well as create and update models. Then, for the “model_id” column, use “Reconciliation Rules” to prioritize updates from the “FlexeraOne” data source and prevent other data sources from overwriting the “model_id” value. This setting will allow the integration to relate the CIs to a “Flexera Normalized Model” without overwriting the existing “discovery” data.

Question: How does the integration handle categories and taxonomies?

The integration adds multiple levels of taxonomy similar to how ServiceNow’s category usage documentation recommends. For example, if a computer is a notebook, you’d have the categories of computer and notebook. Typically, one of the tiers will match up to an existing, out-of-the-box ServiceNow category, but other tiers may not be included out-of-the-box. In this case, ServiceNow will automatically create the new category. The current, overall taxonomy approach was the one recommended by ServiceNow to avoid the custom field and keep consistent with Flexera’s taxonomy while still typically aligning with the core, out-of-the-box categories that are usually associated to a class or asset type in case someone is using that functionality.

Question: Coalesce—how are records matched up with existing records in ServiceNow?

The coalesce method used with this integration varies, but it is typically handled either by ServiceNow’s out-of-the-box tools, using configuration that is set up outside of this integration, or we use the same values ServiceNow does to match, in most cases.

•

Hardware: This is handled by IRE and uses IRE’s settings/configuration to match. The integration does not alter this behavior.

•

Hardware Models: This will match using our Technopedia ID. Using the name value would usually result in a new model since it wouldn’t match a non-normalized model. To keep this consistent, and to ensure two sources aren’t fighting over a model’s details, we use the Technopedia ID field. This field is also used to help know which models relate to other Flexera normalized data.

•

Software Installations: These are matched using ServiceNow’s Primary key method. This is derived from the values from manufacturer, display_name, and version.

•

Software Discovery Models: These are matched using ServiceNow’s Primary key method. This is derived from the values from manufacturer, display_name, and version.

•

Software Models: Just like Hardware Models, the integration also uses the Technopedia ID field for Software Models, and for the same reasons.

•

Lifecycle Records: These use both the technopedia_id field as well as the lifecycle_phase to coalesce.

Question: Does the integration delete records?

No, absolutely not.

We are well aware that best practice in ServiceNow is to NOT delete CIs and records. Records should be managed as part of processes and, in the event that doesn’t happen, staleness processes in ServiceNow should be used to manage the records. In some cases you might also implement an archive system. Deletion of CIs can have a cascading impact on other records causing a loss of historical data and could also have consequences from a legal and governance perspective.

That being said, we acknowledge that some of our customers were making use of the is_deleted field, especially for software. Therefore, that field itself remains available to use, if needed, but because there is also an out-of-the-box field that’s purpose is essentially the same (Active Install), the is_deleted field is not the recommended approach to managing software installations. We recommend anyone currently using is_deleted switch to using this out-of-the-box field, instead, to ensure compatibility with both ServiceNow and Flexera moving forward.

Question: How is CI Classification handled in this integration?

Primarily, we use Technopedia taxonomy to match up to a logical classification match based on the Platform Type and Platform Label fields (for example: Server, Windows) passed from our APIs. These fields are used to relate to a class in our Robust Transform Map for Hardware Inventory to know which class it should be associated with.

Question: Are Asset records created or managed as part of this integration?

No. This integration does not directly interact with Asset tables in ServiceNow. The Flexera One integration does not create or manage records in those tables. However, many out-of-the-box options exist that will automatically handle synchronization between CIs (Configuration Items) and Assets—including creating a matching asset and updating changes between them.

Question: How are Flexera and ServiceNow lifecycle states correlated?

Flexera and ServiceNow have similar naming conventions for the different lifecycle states but there are exceptions. With the Flexera One integration, we’re mapping three key lifecycles between Flexera One and ServiceNow:

•

General Availability

•

Last Availability (hardware)/End of Life (software)

•

Obsolete

For details, see the Hardware Lifecycle and Software Lifecycle tables below.

Hardware Lifecycle

Hardware Lifecycle
Flexera	ServiceNow
General Availability	General Availability
Last Availability	End of Sale
Obsolete	End of Extended Support

Software Lifecycle

Software Lifecycle
Flexera	ServiceNow
General Availability	General Availability
End of Life	End of Life
Obsolete	End of Extended Support

Question: How does Flexera handle missing lifecycle event dates?

Some dates you may see are referred to as “placeholder” dates. These placeholder dates are easy to identify, and the value you see depends on the specific exception related to that date. The following list explains what each placeholder date means.

•

1900 means the date is in the past. This is used when there is no published date by a manufacturer/publisher, but it’s obvious that it happened in the past. The 1900 value is mostly used for old hardware or software.

•

2999 means the date is TBD (To Be Determined). The 2999 value is used if a manufacturer/publisher has not yet published a date. Typically, this occurs for end-of-life dates that have not yet been officially determined or set by the manufacturer. We expect these dates to change once the manufacturer has decided on a date. At that time, we will update the placeholder date with the manufacturer’s published date.

•

3999 means there is no “real” date for this lifecycle stage for this product. Typically, the 3999 value is used for things like SaaS software or virtual devices that have no “end-of-life” date, but it could also apply to other similar situations. The expectation if you see this date is that it will not change as there is no expectation a manufacturer/publisher would ever have a date for this product.

Question: How does Flexera map if a product or release is licensable compared to the ServiceNow approach?

ServiceNow maps the licensable value at the product level. This approach is typically accurate enough, but it is not always correct—as sometimes, even within a product, specific releases may or may not be licensable.

Flexera maps the licensable value at the release level. This approach is more often the most accurate way to map the licensable value.

Note:Flexera also includes a mapping at the product level as a general indicator of licensable versus not licensable products—as determining licensability at the product level has some utility even though it cannot match the degree of certainty possible at the release level.

Question: Is it possible to exclude specific tables or classes from the ServiceNow export to Flexera?

Yes. The integration includes a section for export filters. These filters are created using the standard ServiceNow table filters that you create when in list view, and these filter queries can be copied to Notepad. Then, you can paste that filter query into the export line for the related table to send only the same data that filter would include in the list view—making it easy to verify you are exporting exactly what you want. If you wish to send nothing at all for a table, it is as simple as making a filter that would not return that data. No separate property or setting is required. You can even exclude the entire data set easily by creating a filter that would never return a record.