ServiceNow Software Model Explained

What is the Software Model?

The software model in ServiceNow tracks software applications, their installations on hardware assets, and the entitlements (licenses) that permit their use. It captures which users have which software on which devices, how many licenses are owned, and where those licenses are deployed. This model is essential for software asset management (SAM), compliance audits, and cost optimization because it prevents over-licensing while ensuring compliance with vendor license agreements.

How the Software Model Works on the Platform

The software model consists of several linked tables. The Software table defines applications (Microsoft Office, Adobe Creative Suite, Slack, Salesforce, etc.) with their metadata (vendor, category, release date, support status). The Software Installation table links software to Computing Devices (laptops, desktops, servers), showing which version of each application is installed on which machine. The License Entitlement table tracks how many licenses of each application are owned, their expiration dates, and their terms (per-seat, per-core, perpetual, subscription).

When you run software discovery via a MID Server or endpoint management tool, ServiceNow scans installed software on all managed devices and creates or updates Software Installation records automatically. You then compare installed software to owned licenses in a reconciliation report. If you have 50 employees but only 30 Office licenses, you are non-compliant. The software model surfaces this gap so you can either purchase more licenses, uninstall software from machines that do not need it, or document a compensating control (e.g., shared licenses on a server).

Where the Software Model Lives

The software model is part of the ITAM (IT Asset Management) module. Software records, installations, and entitlements are stored in separate tables but linked by sys_id. Discovery tools populate installations automatically; no manual data entry for discovered software. You manually create or import entitlement records from your license agreements (purchase orders, vendor contracts). Reconciliation reports compare installations to entitlements and flag mismatches. Vulnerability data can also link to the software model: if a vulnerability affects Office recent years, ServiceNow can flag all devices with that version as vulnerable.

Worked Example: License Compliance Audit

An audit report shows you have purchased 100 licenses of a design application but discovery found 150 installations on user machines. You are using 50 more seats than you have purchased, which is a compliance violation. You can negotiate with the vendor to reduce your license count (if the seats are false positives) and save money, or verify that some installations are in test/dev labs and update the inventory to exclude them from the SAM process. The software model makes this visible; without it, you would overpay for licenses every year without knowing you were over-provisioned.

Common Misunderstandings

Many organizations believe the software model automatically enforces compliance. It does not. The model reports what exists; enforcing policies requires governance and process discipline. If someone installs unapproved software on their laptop, the software model will detect it during the next discovery run, but someone must review the detection, and someone must take action (uninstall, purchase a license, or approve an exception). Without process, the model is just data collection.

Another misconception: that discovery tools capture all software. They do not. Most discovery captures installed applications (Windows registry, Linux package managers) but misses browser extensions, scripts in user home directories, portable applications (USB drives), or software installed in non-standard paths. Organizations with strict compliance requirements must supplement automated discovery with manual spot-checks or endpoint detection tools that see everything running in memory.

Some assume the software model handles subscription licenses correctly. Subscriptions change entitlements over time as contract renewal dates arrive. The software model stores a snapshot of licenses on a date; subscriptions that expire or renew require manual updates to the Entitlement records. This is a gap that requires process discipline (calendar reminders for renewal dates).

Related Concepts

Computing Devices are hardware assets that software installs on. Vendors are the publishers (Microsoft, Adobe, etc.). Software Categories help organize applications by function. Licenses are legal contracts; Entitlements are the specific terms (quantity, expiration date, usage rights). Discovery is the automated process of finding and cataloging installed software across all devices.

Reporting and Governance

Common reports include: number of installations vs. licenses (compliance status), software by department (cost allocation by business unit), expiring licenses (renewal reminders), and unapproved software detected (policy violations). Use these reports to drive procurement decisions, negotiate volume discounts with vendors, and enforce policy across the organization. Review software inventory monthly to stay current and catch new installations or removals quickly. Track license spend trends over time to identify opportunities to consolidate vendors or renegotiate terms.

Why the model is only as good as its names

Discovery reports software using whatever string the installer or operating system provided. The same product can arrive as a vendor’s marketing name, a short internal code, a version-stamped package name, or a localized label, and each variant can come from a different machine. A model that stores each variant as its own product will show many separate applications where there is one, and any compliance count built on it will be wrong in both directions. Much of the design effort in a software model therefore goes into normalization: deciding which discovered names refer to the same product, and recording that decision in a way that can be reviewed.

The reporting that leadership sees is downstream of that work. If the normalization is loose, the reports will look precise while being unreliable, and that is a harder problem to correct once decisions have been made on the numbers.

Mapping discovered signals to products and editions

Each discovered record carries several signals, and no single one is reliable on its own. The table shows how to treat each signal when deciding which product a record belongs to.

Discovered signal	Reliable for	Unreliable for	Treatment in the model
Publisher name	Grouping products under one vendor	Telling products apart within a vendor	Use to narrow candidates, never to match alone
Product name string	Identifying the family of a product	Editions, suites and localized labels	Map through a maintained name list, reviewed on change
Version string	Identifying the release in use	Whether the entitlement covers that release	Store on the installation, compare to the entitlement separately. Version data also feeds any vulnerable item view.
Install location	Spotting unusual or portable installs	Identifying the product on its own	Use as a flag for review, not as a match key

The version row is where many models overreach. A version string tells you what is on the machine. Whether the organization is entitled to run it is a separate fact, held on the entitlement, and the two should be compared rather than merged.

Keeping installations separate from products

The model holds two kinds of record that are easily confused. A product describes the software as a thing an organization can buy and govern. An installation describes one copy on one device at one time. A single product will have many installations, and an installation should always point to exactly one product. When an installation cannot be matched, it should sit in a review queue rather than being attached to the nearest product, because a wrong attachment inflates one product’s count and hides the gap in another.

Keeping this separation clean also makes reconciliation possible later. Counts can be taken from installations, compared with entitlements, and explained, without the product record itself needing to be rebuilt each time discovery runs.

Normalization rules that a reviewer can check

Normalization rules work best when they are small, explicit and recorded with the reason for each. The steps below describe a sequence that keeps the rules auditable.

1. Export a sample of discovered names for the last discovery cycle, with the publisher and version attached, and group the names that look alike.
2. For each group, decide whether it is one product, several editions, or something unrelated, and record the decision with the evidence used.
3. Write the matching rule with the narrowest pattern that captures the group, so that a future product with a similar name is not swept in.
4. Route every name that matches no rule to a review queue with an owner, rather than to a catch-all product.
5. Run the rules against the previous cycle’s data and count the changes before enabling them, so that the effect on the reports is known in advance.
6. Review the rule list on a fixed cadence, and retire any rule whose product no longer appears in the estate.

Stale installations and the devices that no longer exist

A model that is never cleaned will keep software on devices that were reimaged, retired or replaced. Installations linked to hardware that is no longer in the estate look like live use and inflate counts. The remedy is in the reconciliation between discovery and the hardware inventory rather than in the software records themselves. The identification and reconciliation engine is where duplicate and stale identities are resolved, so changes to how devices are identified should be tested against the software model before they are trusted.

Reimaging is the common case. A device that is rebuilt often receives a new identity while its old installations remain attached to it, and the same software then appears twice. The reconciliation and duplicate control guidance covers the rules that prevent that doubling.

When reconciliation results should go to a person

Not every mismatch needs an automated answer, and some should never be closed by a rule. A product that appears on a large number of devices with no entitlement is a decision for a person who can check the contract. A product on a single device that is a known test machine is a candidate for a documented exclusion. The model should make the distinction visible, so that the automated mismatches are cleared quickly and the judgment calls reach someone with authority to make them.

Governance over the outcome matters as much as the data. Recording who approved an exception, and when it falls due for review, is covered in the software asset lifecycle controls guidance.

Questions about the software model

How often should discovery feed the software model?

Discovery results often reach the platform through a MID server, so the cadence depends on that path as well as on the schedule. Often enough that a new installation is seen before it becomes a compliance question, and not so often that the reconciliation queue is always full of changes nobody has time to review. Choose the cadence with the review capacity in mind, and adjust it after a few cycles.

What is the difference between the software model and the entitlement records?

The software model records what is installed and how it is named. The entitlement records state what the organization is allowed to run. Reconciliation compares the two. Keeping them separate means a change to one does not silently rewrite the other.

Should every discovered product be modeled?

No. Modeling is worth doing for products that carry a license obligation, a security exposure or a significant cost. Utilities and small components can often be left as unmodeled installations, provided the decision to leave them out is recorded.

Who should approve a new normalization rule?

The software asset lead, with a second reviewer who knows the product. A rule that merges two products can change counts across the whole estate, so it should not be approved by the person who wrote it alone.