Use of product model, service model in Service Specifications, Resource Specifications in SOMT

[snehapatel]

Hi,

In the demo data, I have observed that many of the service specifications, resource specifications have associated product models & service models. Also during CI creation in the fulfilment flows the model ID is referred. In context of this :

1. My understanding is the product models is primarily used in Asset Management  and for mapping assets to CI. Why would product model and service models be needed for the projects wherein HAM/SAM is not used.
2. When creating service specifications, I do not see any option on the CSM/FSM configurable workspace to associate service model with it. 
3. In the example fulfilment workflows, I see the model id being populated whenever a CI record is created in CMDB. Does it mean product model/service model should be associated with service/resource specifications.

Also it would be good to have some pointers when creating CI or modelling the products in SOMT so that assurance use cases also work fine.

Thanks,

Sneha

[pavani_paluri]

Hi @snehapatel ,

Here is my understanding on Models in ServiceNow, when you create services or resources, the system often ties them to models (like product models or service models).
These models are basically templates that say: “This is what this thing looks like in the CMDB — what type it is, what fields it has, how it behaves.”
Even if you’re not using Asset Management (HAM/SAM), models are still useful because they keep your CMDB clean and consistent.

Why models matter
- Consistency: When fulfilment workflows create a CI (Configuration Item), the model ID makes sure it’s created with the right details.
- Assurance/Monitoring: If you want to track health, incidents, or impacts later, the system needs to know what kind of CI it is — the model provides that.
- Governance: Models prevent random, messy CI records from being created. They enforce rules.

 Models are blueprints. Even if you don’t track assets, use them so your services and CIs are consistent, and assurance tools can do their job properly.
If requirements change, you don’t have to invent new logic — just reuse the right model so assurance and monitoring tools can recognize the CI.

Mark it helpful if this helps you to understand. Accept solution if this give you the answer you're looking for

Kind Regards,

Pavani P