Payment Device model category requires Retail Model, but Retail Model has several complications

[Greg Hoschar]

I'm evaluating the out-of-box Payment Device CI class (cmdb_ci_payment) and am struggling to understand the intended lifecycle for Retail Models (sn_ent_retail_model).

The Payment Device model category specifies:

• CI Class: Payment Device (cmdb_ci_payment)
• Product Model Class: Retail Model (sn_ent_retail_model)
• Asset Class: Retail Asset (sn_ent_retail_asset)

However, after installing and updating the Expanded Model and Asset Classes application, Retail Model does not appear as an option in the "What type of model would you like to create?" wizard.

Observed behavior

1. Retail Model does not appear in the New Model wizard.
2. I can create a Hardware Model and then reclassify it to Retail Model.
3. While still a Hardware Model, I can assign the Payment Device model category.
4. After reclassification, the Payment Device category persists and the record appears valid.
5. Once the record is a Retail Model, the Model Categories field no longer appears editable.

Questions

• What is the intended use case for Retail Models?
• What is the supported method for creating Retail Model records?
• Is it expected that Retail Models are omitted from the New Model wizard?
• Is it expected that Model Categories become non-editable after reclassification?
• Has anyone successfully implemented Payment Device CIs using the out-of-box Payment Device model category?

Environment

• Expanded Model and Asset Classes (sn_ent) installed and updated to latest available version.
• Payment Device category references sn_ent_retail_model as Product Model Class.
  
  

[KPNow · Accepted solution]

Please see my responses below with a  breakdown of how ServiceNow handles Retail Models (sn_ent_retail_model) within Enterprise Asset Management (EAM) and how to address the quirks you may be seeing:

1. What is the intended use case for Retail Models?

Retail Model is designed specifically for Enterprise Asset Management (EAM)focused on retail environments. It covers point-of-sale (POS) terminals, receipt printers, barcode scanners, self-checkout kiosks, and card readers/payment devices (like the Ingenico Lane 3000).

The main reason ServiceNow separates these into their own table instead of standard Hardware Management (alm_hardware) is to allow retail-specific lifecycles, store-level inventory auditing, bulk deployments, and specialized maintenance workflows.

2. What is the supported method for creating Retail Model records?

In ServiceNow EAM, models under the Enterprise schema are typically created through:

1. Enterprise Asset Management Workspaces / Menus:
   
   
   Navigating directly to Enterprise Asset Workspace > Product Models or via the classic navigator under Enterprise Asset Management > Models > Retail Models, then clicking New.
2. Direct Table Access:
   
   
   Navigating directly to sn_ent_retail_model.do in the filter navigator.
3. Model Management Sourcing / Procurement:
   
   
   Automatically generating model records during enterprise procurement, normalization, or vendor catalog ingestion.

3. Is it expected that Retail Models are omitted from the New Model wizard?

Yes, this is an expected UI limitation.

The Interceptor/Wizard page (/cmdb_model.do?sys_id=... or standard "Create New Model" interceptor) shown in your screenshot relies on a legacy base-platform list of cmdb_model child classes. Enterprise Asset Management (sn_ent) introduces scoped tables outside the standard ITAM model creator interceptor. ServiceNow frequently omits scoped Enterprise model classes from the legacy global interceptor, requiring you to create them directly from the Enterprise Asset workspace or direct table navigation instead.

4. Is it expected that Model Categories become non-editable after reclassification?

Yes, this is standard platform behavior.

• Why it locks: When a model is classified under a specific scoped Enterprise Model class (like sn_ent_retail_model), ServiceNow's form policy/UI policy locks the Model categories field to enforce tight coupling between the specific asset class, CI class, and model class defined in the Model Category rule.
• Reclassification side effect: When you created it as a Hardware Model first and reclassified it, the system mapped the category during reclassification and then locked the field to prevent misalignments between cmdb_ci_payment and sn_ent_retail_asset.

5. Has anyone successfully implemented Payment Device CIs using the out-of-box Payment Device model category?

Yes, but almost exclusively when Enterprise Asset Management (EAM) is fully configured. I’m sure others might have a different opinion.

If you are using the out-of-box mapping:

• Model Class: Retail Model (sn_ent_retail_model)
• CI Class: Payment Device (cmdb_ci_payment)
• Asset Class: Retail Asset (sn_ent_retail_asset)

Common Pitfall & Practical Recommendation:

• If you have full EAM licensing and modules active: Stick with the OOB setup. Create models via sn_ent_retail_model.do or through the EAM Workspace rather than reclassifying Hardware Models.
• If you only have standard ITAM (Hardware Asset Management) and standard CMDB: The sn_ent_retail_asset table enforces EAM logic. Many organizations without active EAM workflows change the Payment Device Model Category definition so that:
  
  
  • Product Model Class = Hardware Model (cmdb_hardware_product_model)
  • Asset Class = Hardware (alm_hardware)
  This keeps payment terminals inside standard HAM/ITAM workflows without running into table-scoping and UI restrictions.
  Hope this helps. Cheers.

[Greg Hoschar]

@KPNow: Thank you! That was very helpful.

I have two follow-up questions:

1. What is the preferred/supported way to modify Model Category class mappings?

Our organization currently uses CMDB together with the asset-management capabilities available in the base platform. We do not currently license HAM or EAM, although HAM is a likely future direction.

We do, however, have the following applications installed:

• CMDB CI Class Models (sn_cmdb_ci_class)
• Expanded Model and Asset Classes (sn_ent)

The sn_ent application was installed as a dependency of sn_cmdb_ci_class. The Retail-related classes appear to come from sn_ent.

We would like to use the OOB Payment Device CI class and related data model for our credit card readers, rather than creating custom classes.

ServiceNow appears to enforce a one-to-one relationship between CI Class and Model Category, so creating an alternate Model Category mapped to the same CI Class does not seem to be an option.

In my PDI, even as an admin, I am unable to modify the Product Model Class, CI Class, or Asset Class values after they have been assigned.

As a proof of concept, I exported the Model Category record to XML, manually changed the class references, reimported it, and set Out of Box Category = No. This appears to work, but it feels more like a workaround than a supported configuration approach.

Another option would be to delete the OOB Model Category and create a new one from scratch. That feels equally uncomfortable from a governance and supportability perspective.

Is there a supported mechanism for changing these mappings, or are they intentionally designed to be immutable once created?

2. Are there any long-term concerns with modifying the OOB Payment Device category itself?

Are there any upgrade, supportability, normalization, licensing, or future HAM/EAM migration concerns associated with changing the OOB Payment Device category to better align with a non-EAM implementation?

[KPNow]

Hi @Greg Hoschar !

1. Changing the Model Category → CI Class mapping

As far as I know there isn't a supported admin-UI path for this, and that's by design, not an oversight.

OOB Model Category records get locked down (via UI policy tied to the "Out of Box Category" flag) specifically so people can't accidentally break CI Class Manager and the model normalization logic that ServiceNow ships and patches over time. What you did is a known trick, but it's exactly that: a trick. It bypasses the UI policies and business rules that normally protect that record, and you're now on the hook for maintaining it yourself since ServiceNow will treat it as customized going forward (which is actually the point of flipping that flag : it tells the platform "don't overwrite this on upgrade," but it also means you stop getting any OOB improvements to that category).

Before going further down that road, it's worth asking whether you might actually need a new Model Category at all. The 1:1 pairing you're running into isn't a hard database constraint; it's really a UX/normalization convention. In most cases you don't need a separate category just to create Product Models against the OOB Payment Device class; you can create your models directly under that class using the existing category. A new category is really only needed if you want a materially different set of fields or behavior in the "Create New Model" flow.

If you do need something different, the cleaner pattern is to build your own Model Category (Out of Box Category = No) alongside the OOB one rather than repointing or deleting the OOB record. It's a bit more setup, but it keeps the platform's own data model intact and keeps you clear of update-induced surprises.

2. Risks of modifying the OOB Payment Device category

A few things to weigh:

Upgrades – Once you mark it customized, you stop inheriting any future fixes or enhancements ServiceNow makes to that class/category. You own it from here.

Normalization – CI/model normalization and reconciliation logic can key off category, manufacturer, and model combinations. Repointing the class can produce mismatches that are hard to trace later.

CI Class Manager / CSDM alignment: Reporting, hierarchy views, and CSDM audits generally assume OOB class/category pairings are unmodified. A customized mapping can throw off those views or health checks.

Future HAM/EAM – This is probably the bigger one for you. Payment Device is a class HAM leans on directly for hardware lifecycle. If you license HAM/EAM later and the category's been altered, you'll likely need to reconcile or partially rebuild that configuration before HAM setup behaves as expected and Now Support may not want to touch a modified OOB record if something breaks in the meantime.

if the OOB Payment Device CI class fits your data model, use it as-is and avoid touching the category. If you need different asset-side behavior, build a parallel, clearly custom Model Category rather than converting the OOB one: it costs a little more setup now but saves you a much messier untangling job if/when HAM comes into play.

Cheers!