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]

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.