Connect every PC to its user, asset, and contract

Personal computers in ServiceNow: connect the device to its operational context

A PC record on its own tells you surprisingly little.

Knowing that a laptop or workstation exists is useful, but the operational questions usually come next. Who is using it? Which hardware asset does it belong to? Is that asset leased or owned? Does an active contract apply? Which team manages the device? Is the recorded serial number actually the one printed on the machine?

Those relationships are what turn an inventory record into something that can support IT asset management, support, lifecycle decisions, financial control and governance.

CSDM does not define PCs directly – but the surrounding data still matters

Personal computers, laptops and workstations are not a specific focus of the CSDM model.

That does not mean they sit outside good ServiceNow data management.

PC records depend heavily on the Foundation and product data around them. A device may reference a user, managing group, location, hardware model and lifecycle information. Its corresponding hardware asset can add financial, procurement and contract context.

ServiceNow's CSDM Foundation domain documentation describes product models as reusable reference data and notes that CIs can reference Product Models through the Model ID attribute. Hardware models are one example of that structure.

For a PC, this means that data quality is not simply about whether the device record exists. The surrounding references need to be complete, valid and internally consistent.

Separate the PC configuration item from its hardware asset

One of the most useful distinctions in the session is between the PC as a configuration item and the hardware asset associated with it.

The configuration item represents the device from an operational perspective. It can support processes such as incident and change management and contain details such as:

• Assigned user
• Serial number
• Lifecycle status
• Managed by person or group
• Hardware model

The hardware asset represents another side of the same physical device, including financial and contractual information.

That is where relationships such as leases, rentals, loan agreements and other contracts become relevant.

The two records therefore describe different aspects of the same device. A useful data-quality model needs to check both.

Check whether the user, asset and contract relationships are actually valid

The Personal Computers Blueprint begins with a relatively simple model.

Each relevant PC should be connected to an appropriate user and hardware asset. Where the asset type requires contract coverage, the hardware asset should also link to the relevant active contract.

The current Personal Computers – Connected to Users and Contracts Blueprint uses this model to check whether PCs have an active user, valid hardware asset and appropriate contract relationship.

The checks can go further than simply asking whether a reference field contains something.

For example, a Blueprint can check whether the assigned user is still active or whether a contract remains valid. The requirement therefore becomes:

Does this PC point to a valid record that meets the condition we expect?

rather than:

Is this field populated?

Extend the Blueprint as your PC data requirements mature

The recording demonstrates how the initial Blueprint can be expanded with additional requirements.

Mikko adds a Managed by user and Managed by group, hardware-model references and additional relationships between the PC and its associated asset.

The exact requirements will vary between organisations.

A workplace team may care particularly about user assignment and location. An IT asset management team may place more emphasis on asset linkage, model and contract coverage. A CMDB owner may also need responsibility and lifecycle fields to be consistently maintained.

DCM Blueprints allow those requirements to be represented within the same model rather than treating every field or relationship as an independent quality check.

Check that related records agree with each other

Completeness is only one part of data quality.

A PC and its hardware asset may both contain a model reference, but the data can still be inconsistent if the two references point to different hardware models.

In the demonstration, cohesive links are used to require both references to point to the same record.

The same principle can be applied elsewhere. For example, if the Managed by person is expected to be the manager of the assigned user, the Blueprint can represent that relationship as part of the model.

This moves the audit beyond isolated mandatory fields.

It asks whether related records tell a consistent story about the same device.

Use audit and remediation for problems the data itself can reveal

Once the Blueprint is published, DCM can continuously audit the relevant PC records against those requirements.

In the demonstration, the domain-level view exposes issues such as missing Managed by groups, missing asset relationships and records that do not comply with a newly introduced naming rule.

The people defined as data providers can then be connected to the relevant findings.

For example, the Managed by user or Managed by group might be responsible for maintaining the data for a set of devices.

Those people can see the records and issues relevant to them in the Data Quality Workspace and remediate missing information.

This works well for requirements that ServiceNow can evaluate from the data already available.

But some PC questions cannot be answered from the database alone.

Audit tells you what the data says – attestation can confirm what is actually true

This is where the session introduces a useful distinction.

An automated audit can tell you:

• Whether a PC has an Assigned to user
• Whether the user record is active
• Whether a serial number is populated
• Whether an asset relationship exists
• Whether the required contract relationship is present

It cannot necessarily tell you whether the person listed in ServiceNow actually has that particular laptop sitting in front of them.

It also cannot independently confirm that the serial number recorded in ServiceNow matches the serial number physically associated with that person's device.

Those are questions for a human.

In the demonstration, DCM Data Certification is therefore used as an attestation mechanism. The person assigned to the PC receives a certification task containing only the information they are expected to verify.

Ask device users to verify only what they can reasonably know

One of the strongest parts of the example is that the employee does not receive the entire Blueprint.

The underlying data-quality model can contain many requirements covering assets, contracts, models, ownership and lifecycle information.

The certification task shown to the device user contains only two selected elements:

• The Assigned to information
• The serial number

That distinction matters.

An employee can reasonably answer:

Is this my computer?

and:

Does this serial number match my device?

They should not necessarily be responsible for determining whether the hardware asset is linked to the right procurement contract or whether the CMDB ownership model is correct.

Different responsibilities can therefore be drawn from the same Blueprint.

The data provider can remediate the wider data-quality gaps, while the device user verifies a much smaller subset of facts.

Give people enough guidance to complete an attestation correctly

A certification task is more useful when the person receiving it understands exactly what they are being asked to verify.

In the recorded example, the task includes instructions explaining how the user can find the serial number on a Windows computer.

Additional certification guidance tells the user what action to take:

• If the device belongs to them and the details are correct, certify the information.
• If the assignment is incorrect, reject it and provide a comment.
• Do not change data that the user is not responsible for maintaining.

The guidance can also require acknowledgement before the user is allowed to certify the record.

This makes attestation different from simply emailing employees a spreadsheet and asking them to review their device details.

The question, context and permitted actions can all be defined around the particular verification task.

One Blueprint can support different responsibilities

The demonstration uses one underlying Blueprint for two related but different purposes.

From a data-quality perspective, the Blueprint contains a wider model covering the PC, user, asset, model, groups and contracts.

From an attestation perspective, only selected Blueprint elements are included in the certification task.

The task can also be assigned to a different person.

For example:

• The Managed by user or group can act as the data provider responsible for remediating PC data.
• The Assigned to user can receive the certification task asking them to verify the device they use.

That makes it possible to divide work according to who actually knows the answer rather than assigning every data-quality activity to one central team.

How should you handle shared PCs and loan devices?

Not every computer should have a permanent individual user.

Shared workstations, pool devices and loan laptops are obvious examples.

An empty Assigned to field may therefore be a genuine data-quality issue for one PC and completely correct for another.

The answer demonstrated in the Q&A is to make the requirement conditional.

If the PC record contains information identifying it as a shared device, the Blueprint can apply different requirements. For example, a shared PC might need to reference a responsible group rather than an individual user.

The important principle is:

model legitimate exceptions rather than weakening the rule for every record.

A conditional requirement allows individual PCs to require a valid assignee while shared devices follow a different ownership pattern.

What if an employee leaves before the laptop is returned?

Employee departures create another common edge case.

A laptop may still be physically in transition while the user associated with it has already left the organisation.

The Blueprint can check more than whether Assigned to contains a reference. It can also check the target user record against conditions such as whether the user is active.

When an HR system, identity platform or another authoritative source marks the user inactive, the next audit can expose that relationship as invalid.

The issue can then be directed to the person responsible for maintaining the PC data.

This allows the record to remain visible as something requiring attention rather than silently treating the former employee as a valid assignee.

Repeated PC issues can reveal a broken process, not just bad records

Fixing individual records is useful, but hundreds of identical findings usually point to something larger.

The Q&A gives a good example.

If almost every PC fails a newly introduced naming convention, manually correcting hundreds of devices addresses the symptoms. The more important question is why the process creating those records does not apply the naming rule in the first place.

The same applies to repeated missing lifecycle states, ownership information or relationships.

Aggregated problem-area reporting can reveal which Blueprint requirements generate the largest number of findings.

That gives the data owner a basis for investigating the upstream process, integration or governance rule behind the recurring issue.

The goal is therefore not only:

How do we fix these 300 PCs?

It can also become:

What needs to change so the next 300 PCs are created correctly?

Connect client devices to the wider service model when it adds value

The session also touches on another layer beyond the core user, asset and contract model.

Client devices can be grouped using Dynamic CI Groups based on attributes such as location, model or manufacturer.

ServiceNow describes Dynamic CI Groups as collections of CIs created from shared attributes or criteria and documents their use with Technology Management Services and offerings.

This creates useful possibilities for workplace services.

For example, PCs at a particular location could be grouped under an offering representing on-site support for that location. Devices from a particular manufacturer could be grouped into a technical support context based on the way that equipment is managed.

The ServiceNow documentation on Dynamic CI Groups and service types provides the underlying CSDM guidance.

This also shows why apparently simple PC attributes such as location and hardware model can have value beyond asset inventory.

For the location side of that relationship, see the ServiceNow Location Data Blueprint Live recording, which demonstrates how locations and their ownership can be governed as Foundation data.

Start with the device relationships that matter most

PC data can become complicated quickly if every possible hardware, asset, lifecycle and service relationship is introduced at once.

A more practical starting point is to define a small baseline:

• Who is using the device?
• Which hardware asset represents it?
• Does the asset have the required contract?
• Who manages the data?
• Are key identifiers such as serial number present and valid?

Audit those requirements continuously and give the resulting findings to the people responsible for maintaining them.

Then identify the questions that an automated audit cannot answer with confidence.

For those, targeted attestation can involve the person closest to the physical device without asking them to become responsible for the entire CMDB record.

The Personal Computers – Connected to Users and Contracts Blueprint provides a ready-made starting point that can be adapted to your organisation's device classes, ownership model, asset processes and contract requirements.