Claire_Conant
ServiceNow Employee
Options
- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
an hour ago
If you've ever run a Discovery schedule and come back to find CIs in different classes than when you left, you're not imagining things. The IRE is doing exactly what its default properties tell it to do. The problem is those defaults are more permissive than most admins expect, and two of the three reclassification types can cause permanent attribute loss before you realize anything happened. This article walks through the behaviors that tend to surprise people, why they happen, and how to get deliberate control over when and whether reclassification occurs.
These scenarios apply to your environment if:
- You use Discovery, Service Mapping, or third-party integrations that push CI data through the IRE
- You’ve seen the error “CI Reclassification not allowed” in your Discovery or integration logs
- You have CIs stuck in generic parent classes like cmdb_ci_computer that should be in more specific child classes
- You’ve noticed unexpected class changes on CIs after a Discovery run or integration sync
If you’re running any currently supported ServiceNow release with the base system property defaults, all these scenarios are relevant to your instance right now.
The three reclassification types and their risk profiles
Every scenario in this article depends on understanding the difference between these three reclassification types. The data risk varies significantly; upgrades are safe, but downgrades and switches can cause permanent data loss.
|
Reclassification Type
|
What happens
|
Data risk
|
|
Upgrade
|
CI moves from a parent class to a more specific child class (for example, cmdb_ci_computer → cmdb_ci_linux_server)
|
None. Child classes inherit all parent attributes and add new ones.
|
|
Downgrade
|
CI moves from a child class to a more general parent class (for example, cmdb_ci_server → cmdb_ci_computer)
|
Permanent attribute loss. Fields or attributes unique to the child class are dropped.
|
|
Switch
|
CI moves to a sibling class in a different branch (for example, cmdb_ci_linux_server → cmdb_ci_win_server)
|
Permanent attribute loss. This is effectively a downgrade followed by an upgrade.
|
How the IRE evaluates reclassification
When the IRE receives a payload with a className that differs from a CI's current class, it evaluates three layers of control in order. Understanding this sequence explains why changing a single property sometimes doesn't produce the result you expect—a higher layer may be resolving the scenario first.
|
Layer
|
What it checks
|
Controlled by
|
|
1
|
Restriction properties—Should the CI be updated without changing its class?
|
glide.identification_engine.update_without_downgrade_enabled, update_without_switch_enabled, update_without_upgrade_enabled
|
|
2
|
Restriction rules—Is there a table-based rule for this specific class-pair transition?
|
cmdb_reclassify_restriction_rule table (enabled by glide.identification_engine.reclassification_restriction_rules_enabled)
|
|
3
|
Allow/block properties—Should reclassification be allowed or blocked?
|
glide.class.downgrade.enabled, glide.class.switch.enabled, glide.class.upgrade.enabled
|
If layer 1 resolves the scenario (restriction properties are true), the IRE updates CI attributes, skips the class change, and does not create a reclassification task. Layers 2 and 3 are not evaluated.
1. The downgrade and switch properties default to true
The property that surprises most admins: downgrades and switches are enabled by default, the same as upgrades. The three properties are:
- glide.class.upgrade.enabled—controls automatic upgrades. Default: true.
- glide.class.downgrade.enabled—controls automatic downgrades. Default: true.
- glide.class.switch.enabled—controls automatic class switches. Default: true.
What to watch for
Upgrades being enabled by default are generally fine. Child classes inherit everything from the parent and add their own attributes, so no data is lost. The problem is that downgrades and switches are also enabled by default, and both cause permanent attribute loss.
Try this instead
Rather than blocking reclassification entirely, use the restriction properties to allow attribute updates while preventing class changes. Set glide.identification_engine.update_without_downgrade_enabled and glide.identification_engine.update_without_switch_enabled to true. When these properties are active, the IRE continues to update CI attributes from incoming payloads but skips the class change entirely—and does not create a reclassification task.
Setting glide.class.downgrade.enabled to false is an alternative but be aware that this can break alert binding when the alert's CI class doesn't match the existing CI class.
2. Integrations and discovery can trigger reclassifications you didn’t expect
What to watch for
When a discovery run or integration sync sends a payload to the IRE with a className that differs from the CI’s current class, the IRE evaluates it as a potential reclassification. If your properties are set to true (the defaults), the reclassification happens silently.
A common example: a Windows cluster CI gets reclassified to an MSSQL class because an integration pushes a payload with a different className. You may not realize it happened until downstream reports break or lifecycle changes appear that don’t make sense.
Try this instead
Before enabling any new integration or Discovery schedule, check what className values the data source sends for existing CIs. If there's a mismatch, set the global restriction properties (glide.identification_engine.update_without_downgrade_enabled and update_without_switch_enabled) to true so the IRE updates attributes without changing the class. For more granular control over individual payloads, use payload-level override flags.
3. There’s no built-in undo for attribute loss after a downgrade or switch
What to watch for
Once a downgrade or switch completes, the attributes that existed only on the original class are gone from the CI record. The platform doesn’t create a backup or audit log of the lost attribute values. If you need those values back, you’re looking at a restore from backup or manual re-entry.
Try this instead
Before performing any planned downgrade or switch, query the CI to document its current attribute values. A quick way to do this is to run a background script that reads all non-empty fields on the CI and logs them:
var gr = new GlideRecord('cmdb_ci_linux_server');
gr.get('sys_id', '<your_ci_sys_id>');
var fields = gr.getFields();
for (var i = 0; i < fields.size(); i++) {
var field = fields.get(i);
var value = gr.getValue(field.getName());
if (value) {
gs.print(field.getName() + ': ' + value);
}
}
Run this before the reclassification so you have a record of what was there. After reclassification, you may need to manually repopulate attributes that exist in both classes but weren’t carried over.
4. Reclassification tasks pile up when properties are set to false
What to watch for
The right call for data safety is to set the downgrade and switch properties to false. But if your Discovery or integrations regularly encounter class mismatches, you’ll accumulate reclassification tasks. You can find a list of these tasks by going to Configuration > Identification/Reconciliation > Reclassification.
The task list can grow quickly if you have a large environment with active discovery schedules. The tasks are there for a reason; each one represents a reclassification the IRE wanted to perform but couldn’t. However, reviewing them one at a time isn’t practical at scale.
Try this instead
Review the reclassification task list regularly. Look for patterns: If the same data source is generating dozens of tasks for the same class transition, that’s a signal to investigate the source rather than process each task individually. You can also use payload-level override flags to allow targeted reclassifications without changing the global properties.
If task volume is the primary issue, consider enabling the restriction properties (glide.identification_engine.update_without_downgrade_enabled and update_without_switch_enabled). When these are true, the IRE updates CI attributes without changing the class and without creating a reclassification task, which eliminates the accumulation problem entirely for downgrades and switches.
If you need to know why specific tasks are being generated, enable IRE debug logging by setting the glide.cmdb.logger.source.identification_engine property to debug. If logs aren't appearing in the syslog table after setting this property, check whether glide.cmdb.logger.use_syslog.identification_engine is also defined on your instance. This second property controls whether logs write to syslog. It has internal default values and isn't present in the base system, but if it's been added to your instance, it should be set to Type: string, Value: *
5. Testing reclassification in production without a safety net
What to watch for
Reclassification changes are immediate and, in the case of downgrades and switches, irreversible. Testing in production without isolating the change to a single CI first is how most data loss incidents happen.
Try this instead
Test reclassification behavior on individual CIs using background scripts before making any bulk changes. Go to System Definition > Scripts - Background and use the IdentificationEngineScriptableApi to submit a test payload with the target className:
var payload = {
items: [{
className: "cmdb_ci_linux_server",
values: {
name: "testserver01",
serial_number: "TEST123"
}
}]
};
var input = new JSON().encode(payload);
var output = SNC.IdentificationEngineScriptableApi.createOrUpdateCI(
"TestSource", input);
gs.print(output);
If the CI currently exists as cmdb_ci_server and your payload specifies cmdb_ci_linux_server, the IRE attempts an upgrade. The output tells you whether it succeeded or was blocked. To force a reclassification that global properties would block, include the override flag directly in the payload.
var payload = {
items: [{
className: "cmdb_ci_linux_server",
classUpgrade: true,
values: {
name: "testserver01",
serial_number: "TEST123"
}
}]
};
How to handle reclassification per payload instead of globally
You don’t have to change global properties just to handle a specific reclassification. The IRE supports two categories of payload-level override flags, and they do opposite things. Choosing the wrong one is a common mistake, so it’s worth understanding the distinction before using either.
Flags that allow a reclassification for this payload only
|
Flag
|
What it does
|
|
classUpgrade: true
|
Allows an upgrade (parent to child) for this payload, even if glide.class.upgrade.enabled is false
|
|
classDowngrade: true
|
Allows a downgrade (child to parent) for this payload, even if glide.class.downgrade.enabled is false
|
|
classSwitch: true
|
Allows a switch (sibling to sibling) for this payload, even if glide.class.switch.enabled is false
|
Use these when you’ve reviewed the reclassification and confirmed it’s correct. The CI class will change.
Flags that prevent reclassification while still updating the CI
|
Flag
|
What it does
|
|
updateWithoutUpgrade: true
|
Updates the CI attributes without upgrading its class, even if the payload className is a child of the current class
|
|
updateWithoutDowngrade: true
|
Updates the CI attributes without downgrading its class, even if the payload className is a parent of the current class
|
|
updateWithoutSwitch: true
|
Updates the CI attributes without switching its class, even if the payload className is in a different branch
|
Use these when an integration or discovery sends a className that doesn’t match the CI’s current class, but you want the attribute updates without the class change. This is the safer option when you’re not sure whether the reclassification is intentional.
Table-based restriction rules for class-pair-specific control
If you need granular control over specific class transitions—for example, allowing switches between cmdb_ci_linux_server and cmdb_ci_win_server but blocking switches between cmdb_ci_server and cmdb_ci_router—the cmdb_reclassify_restriction_rule table provides class-pair-specific rules.
This feature is controlled by glide.identification_engine.reclassification_restriction_rules_enabled (default: true). When enabled, the IRE checks the restriction rule table for a matching source class → target class → restriction type entry before evaluating the allow/block properties.
What to do after an unexpected reclassification
While you investigate, set glide.class.downgrade.enabled and glide.class.switch.enabled to false to prevent further automatic changes.
Identify what happened
- Go to sys_properties.list and search for glide.class to check current property values.
- Review the reclassification task list at Configuration > Identification/Reconciliation > Reclassification.
- If a task exists, the change was blocked; if not, the property allowed it through.
- If data was lost, check whether a backup or clone contains the original attribute values.
Decide how to handle reclassification going forward
- Prevent class changes while keeping attribute updates. Set the restriction properties (glide.identification_engine.update_without_downgrade_enabled or update_without_switch_enabled) to true.
- Allow it globally. Change the appropriate glide.class property to true. This affects all future payloads.
- Allow it for a specific payload. Add the classUpgrade, classDowngrade, or classSwitch flag to the payload.
- Review manually. Leave the properties set to false and process the reclassification tasks at Configuration > Identification/Reconciliation > Reclassification
Where to go from here
Reclassification is one of those platform behaviors that feels unpredictable until you understand the property layer behind it. Once you do, it becomes something you control deliberately—deciding per-payload, per-class-pair, or globally what the IRE is and isn't allowed to change.
If you run into a scenario that this article doesn't cover, or you're working through the aftermath of an unplanned reclassification, the CMDB Community forum is the right place to bring it. Other admins and ServiceNow engineers actively watch reclassification threads there.
