---
sourceDocument: Yokohama ServiceNow AI Platform Capabilities
sourceDocumentLink: https://www.servicenow.com/docs/r/yokohama/servicenow-platform
Release :
- yokohama
ft:locale :
- en-US
ft:publication_title :
- Yokohama ServiceNow AI Platform Capabilities
ft:clusterId :
- platcap
bundleId :
- platcap
workflow :
- Platform
---
# Foundation domain
# Foundation domain in the CSDM framework {#ariaid-title1}
* Release version: Yokohama
*
* Updated January 30, 2025
*
*  7 minutes to read
Summarize
 Summarized using AI
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.
## Summary of Foundation domain in the CSDM framework
The Foundation domain in the Common Service Data Model (CSDM) framework comprises essential base data tables that support other CSDM domains and ServiceNow products.
This domain is foundational for populating and using the Configuration Management Database (CMDB) but does not itself involve CMDB relationships.
Instead, it contains critical referential data used by process owners, data stewards, product owners, and contract managers to manage business processes, contracts, products, and organizational data consistently across the ServiceNow AI Platform.
Show full answer Show less
## Key Components
* **Business Processes:** Defined workflows with start and end points, stored in `cmdbcibusinessprocess`. They support hierarchical parent-child relationships, criticality, impact assessments, and scheduled reviews to maintain relevance and accuracy.
* **Contracts:** Binding agreements detailed with terms, dates, financials, and related SLAs, stored in the `astcontract` table. Managed through the Contract Management application, contracts link SLAs, vendors, customers, and assets, playing a role in Vendor and Customer Service Management.
* **Products and Product Models:** Product models represent specific versions or configurations of products (software, hardware, services, etc.) stored in the `cmdbmodel` table and its extensions. They help track product ownership, lifecycle status, compatibility, and bundling of components, enabling a product-centric approach to CI management.
* **CMDB Groups:** Collections of CIs grouped by queries or manual selection, stored in `cmdbgroup`. Groups simplify bulk operations on CIs and replace spreadsheet-based CI grouping.
* **Life-cycle Value Pairs:** Standardized lifecycle stages and statuses track the progression of products, assets, contracts, and CIs from inception to end of life. When enabling CSDM, legacy status values are automatically mapped to these standardized pairs to ensure accurate lifecycle tracking and reporting.
* **Common Data:** Non-CI shared data such as organizational structure (companies, business units, departments), locations, groups, and users. Proper planning and maintenance of common data are critical for effective product implementation and business value realization.
* **Location Management:** Enhanced location data attributes (source, location type, managed by group, validation flags, lifecycle stages) facilitate managing complex location hierarchies and federated data sources.
## Practical Benefits for ServiceNow Customers
* **Reliable foundational data:** Ensures other CSDM domains and ServiceNow products have consistent, trusted reference data.
* **Improved lifecycle tracking:** Standardized lifecycle value pairs enable clear visibility and reporting on asset and product status throughout their lifecycle.
* **Efficient contract and business process management:** Centralized contract and business process data supports governance, compliance, and operational efficiency.
* **Product-centric CI management:** Associating logical CIs with product models helps transition to managing IT assets and services around actual products.
* **Streamlined grouping and bulk operations:** CMDB groups enable simplified management of CI sets without manual spreadsheet tracking.
* **Enhanced data governance:** Common data and location management features support data quality, hierarchy, and maintenance across integrated data sources.
## Next Steps
To leverage the Foundation domain effectively, ServiceNow customers should:
* Activate the CSDM plugin to utilize lifecycle stage and status fields and benefit from automatic legacy status mapping.
* Plan and maintain common data such as organizational units, locations, and user groups to support ServiceNow products effectively.
* Use Contract Management and Service Level Management applications to manage contracts and service agreements centrally.
* Associate CIs with product models to adopt a product-centric management approach.
* Utilize CMDB groups to organize and manage collections of CIs efficiently.
The Foundation domain involves tables that contain base data that is referenced from or to objects in the other CSDM domains. Foundation data is required before you can use ServiceNow products or add data to the CMDB.
The tables in the Foundation domain aren't used in Configuration Management Database (CMDB) relationships. Instead, the tables contain critical referential data. Typical users of the domain are process owners, data stewards, product owners, and contract managers.
## Business process {#foundation-domain__section_tdz_sm3_htb}
A business process has a well-defined start and finish. Examples of business processes in the banking industry are the customer onboarding process and the credit check process. Each business process
can have levels of criticality and impact. Business processes are stored in the cmdb_ci_business_process table.
In a parent-child relationship, business processes can be identified by using the parent attribute as a reference to a parent business process.{#foundation-domain__p-def-business-process}
The business process is a manually-maintained CI that can identify declared and determined criticality as well as impact to confidentiality, integrity, and availability. Business processes can be reviewed monthly, quarterly,
semi-annually, or annually. In addition, the next review date can be recorded. For further information, see [Business process management](https://www.servicenow.com/docs/access?context=business-process-overview&version=yokohama&pubname=yokohama-governance-risk-compliance&ft:locale=en-US) and [Create a business process](https://www.servicenow.com/docs/access?context=create-a-business-process&version=yokohama&pubname=yokohama-governance-risk-compliance&ft:locale=en-US).
## Contracts {#foundation-domain__section_qp2_fv2_qmb}
A contract is a binding agreement between two parties. In the ServiceNow AI Platform, contracts contain detailed information such as the contract number, start and end dates, active status, terms and conditions statements, documents, renewal information, and financial terms.
* A contract is not a CI. Contracts use contract model types from the [Product Models](https://www.servicenow.com/docs/access?context=c_CreateAProductModel&version=yokohama&pubname=yokohama-customer-service-management&ft:locale=en-US) module. Contracts are stored in the \[ast_contract\] table.
* Use the Contract Management application to manage and track contracts. See [Contract Management application](https://www.servicenow.com/docs/access?context=c_ContractManagement&version=yokohama&pubname=yokohama-it-service-management&ft:locale=en-US).
* In the Service Level Management application, contracts group together SLAs that relate to a single vendor or customer, as well as the CIs, locations, groups, users, and child contracts that are related to the contract. For more information, see [Define a service contract](https://www.servicenow.com/docs/access?context=define-a-service-contract&version=yokohama&pubname=yokohama-it-service-management&ft:locale=en-US).
* Service contracts used by Vendor Management Workspace can support hardware CIs as part of an SLA.
* In the Customer Service Management product, service contracts define the type of support that customers receive. A contract can include an account and contact or a consumer and the specific assets that are covered. A contract can also include multiple service entitlements and SLAs. See [Define a service contract in Customer Service Management](https://www.servicenow.com/docs/access?context=create-csm-service-contracts&version=yokohama&pubname=yokohama-customer-service-management&ft:locale=en-US).
{#foundation-domain__ul_mtr_2l1_hwb}
## Products and product models {#foundation-domain__section-product-models}
A product model is a specific version or configuration of a product used to manage and track applications on the ServiceNow AI Platform. Product models identify the product owner, team, product status, compatibility with other products, reference to product catalog, and reference objects in the various stages of a product's life cycle.
For more information, see [Product catalog](https://www.servicenow.com/docs/access?context=c_ProductCatalog&version=yokohama&pubname=yokohama-it-service-management&ft:locale=en-US).
Additionally, you can identify the products reaching end-of-life as defined by third party providers or internal product owners. You can also bundle other products as components to represent the set of products that your
organization develops, sells, or uses.
Product models are extended into seven base types: application model (version agnostic), software model (version specific),contract model, facility model, hardware model, consumable model, service model. Products might be
bundled to create a collection or group of products, for example a FlashBlade server (hardware model), or a 24/7 support service (service model).
Product models are stored in the \[cmdb_model\] table or the extended tables aligned to the seven base types. The product model tables are not CIs. Configuration items can use the Model ID attribute to
reference product models. For example, a service offering CI might reference a particular service model that other service offerings of the same type also reference.
Application, service, and software class instance CIs aren't created through Discovery, so their Model ID \[model_id\] values might not refer to product model records. To help you to migrate to a product-centric management paradigm, each instance of a logical CI should be associated with a product model. See [Auto-generate product models for logical CIs](https://www.servicenow.com/docs/0P2vRxn1R6t0yEWWisjkMw "Use the CSDM Product Model Assignment job to auto-generate a product model record (application model, service model, or software model) for each logical CI that is not yet associated with a product model. Product models are ideal for associating CIs that are parts of a single digital product.").
## CMDB group {#foundation-domain__section_imt_5b2_qmb}
A CMDB group is a collection of CIs (but is not, itself, a CI). A group is based on the results of saved Query Builder queries, encoded queries, or manual entries. You can apply an action to
all members of a group at one time.
You can work with a CMDB group across the ServiceNow AI Platform.
* For the CSDM, the Dynamic CI Group references a CMDB group to provide a list of CIs based on a common criteria.
* CMDB groups are stored in the table \[cmdb_group\].
* The CMDB group can potentially replace the spreadsheets that you might be using to group your CIs.
{#foundation-domain__ul_ncg_n5f_zvb}
For additional information, see [CMDB groups](https://www.servicenow.com/docs/yrR0GPFA53y2ifqYVg8geA#cmdb-groups "A CMDB group is a collection of CIs that lets you apply CI actions collectively to all the CIs that are members in the group.").
## Life-cycle value pairs {#foundation-domain__section-life-cycle-states}
life-cycle value pairs track the life cycles for products, assets, contracts, CIs, locations, and other objects. Using the standard CSDM life-cycle values consistently helps you to effectively track objects through their transitions over time. Reporting can therefore accurately reflect the actual states of CIs: usage, availability,
end of support, and so on.
See the ServiceNow Community video: [CSDM V4 product and life cycle discussion](https://www.youtube.com/watch?v=TfRv1VTRsgM)
The standard CSDM life-cycle value pair covers all phases of a product instance life cycle.
* A life cycle stage is one of the broad phases that a CI moves through, from inception or procurement to operation and then to end of life.
* life cycle stage status is the particular status of a CI within its current life cycle stage.
{#foundation-domain__ul_xkz_15s_lrb}For example, a hardware CI in the Operational stage might change stage status over time from In Use to In Maintenance to End of Support. A different hardware CI might go from In Use to End of Support without ever having been in In Maintenance status.
When you enable the CSDM framework, you can start using the Life Cycle Stage and Life Cycle Stage Status values to track an asset's life cycle. To use the fields, follow the procedure described in [Activate the CSDM plugin](https://www.servicenow.com/docs/zEyzFNDr8~VrE4UazZgbJg "Activate the CSDM plugin so you can begin implementing the framework."). The following processes can use the life-cycle value pairs:
* [Product life cycle](https://www.servicenow.com/docs/DtnYoHLdLYGhOCRgiGPQfQ "The CSDM framework provides standard fields and values that you can use to track the life cycle of an asset or a CI. The product life-cycle value pairs represent the overall life cycle of a product model, a specific version, or a product configuration.")
* [Hardware life cycle](https://www.servicenow.com/docs/Mes3o2ApiaeoaMtsgBEl6A "The CSDM framework provides standard fields and values that you can use to track the life cycle of an asset or a CI. The hardware life-cycle states represent the overall life cycle of hardware assets and CIs as related to their products.")
* [Logical life cycle](https://www.servicenow.com/docs/vm31Vm8xN8VXeQcrKAiGig "The CSDM framework provides standard fields and values that you can use to track the life cycle of an asset or a CI. The logical life-cycle value pairs represent the overall life cycle of logical assets and CIs as related to their products.")
* [Document life cycle](https://www.servicenow.com/docs/vDrjnGOXK2nlNsj7TOYWDw "The CSDM framework provides standard fields and values that you can use to track the life cycle of an asset or a CI. The document life-cycle value pairs represent the overall life cycle of document assets (contracts) and CIs (business process) as related to their products.")
* [Location life cycle](https://www.servicenow.com/docs/kr2jV95iyK6670co23sU5w "The CSDM framework provides standard fields and values that you can use to track the life cycle of an asset or a CI. The location life-cycle value pairs represent the overall life cycle of a location within common data.")
{#foundation-domain__ul_h1q_3hg_4tb}
## Legacy status values are auto-updated {#foundation-domain__section_an3_hsb_hwb}
The following legacy statuses are automatically mapped to the Life Cycle Stage and Life Cycle Stage Status fields when you follow the procedure described in [Activate the CSDM plugin](https://www.servicenow.com/docs/zEyzFNDr8~VrE4UazZgbJg "Activate the CSDM plugin so you can begin implementing the framework.").
Important:
Legacy field values are not deleted after you map them to Life Cycle Stage and Life Cycle Stage Status values.
* Product Model Status
* Asset State
* Asset Substate
* Contract Status
* CI Install Status
* CI Operational Status
* CI Hardware Status
* CI Hardware Substatus
{#foundation-domain__ul_k41_jgf_vpb}
## Map existing status values to CSDM life-cycle value pairs {#foundation-domain__section_vss_m2d_dxb}
Use the Life Cycle Mapping module (CSDMLife Cycle Mapping) to specify how your existing life-cycle values should be converted to CSDM life-cycle value pairs. The mapping ensures ServiceNow AI Platform products "see" legacy CIs in your environment. In this example, the existing Pending Install value of the Install Status attribute for hardware CIs will always map to Deploy/Test life-cycle value pairs in the CMDB. See [Map legacy status values to CSDM life-cycle values](https://www.servicenow.com/docs/tZbCuh9B45lz0drE4HIs7g#create-life-cycle-migration "Use the Life Cycle Mapping module to specify how existing legacy status values should be converted to CSDM life-cycle value pairs (life cycle stage and life cycle stage status). You map both asset and CI legacy status values to life-cycle value pairs.") and [Activate align and sync for CSDM life-cycle values](https://www.servicenow.com/docs/tZbCuh9B45lz0drE4HIs7g#activate-life-cycle-migration "Activate life-cycle sync to migrate your legacy asset and CI status settings to the CSDM standard life-cycle value pairs. After the one-time migration process, business rules maintain sync among IBI, asset, and CI life-cycle values.").
## Common data {#foundation-domain__section_pjg_bz2_qmb}
Common data elements are not configuration items. Common data is shared and used throughout the ServiceNow AI Platform. Common data includes organizational structure (Company, Business Unit, Department), locations, groups, and users. Many ServiceNow AI Platform products depend on common data to provide business value.
Planning your common data is essential to the effective implementation of ServiceNow AI Platform products and features. Consider the following issues:
* Do you have a trusted source for the data?
* Do you have multiple data sources?
* How often does the data change?
* Do you have the depth of data that the CIs require?
* Who maintains the data?
{#foundation-domain__ul_q4z_1bf_qmb}
Common data is stored in the following tables:
* Company: \[core_company\]
* Business unit: \[business_unit\]
* Department: \[cmn_department\]
* Location: \[cmn_location\]
* Groups: \[sys_user_group\]
* Users: \[sys_user\]
{#foundation-domain__ul_pql_h2f_qmb}
## Location management {#foundation-domain__section_wmh_nmh_4tb}
Data that comes from multiple sources and federated integrations is difficult to maintain. The following attributes have been added to the location (cmn_location) table to simplify management:
* Source: The origin of the location record.
* Location type: The position of the location record in the hierarchy of locations. You can use the following options to create a hierarchy of location data to suit your requirements: Region, County, State/Province, City, Site, Building/Structure, Floor, and Room.
* Managed by group: The group that governs or manages this location record.
* Validation (duplicate and primary): Flag duplicate records and manually filter locations that are not be displayed.
* Life cycle stage and Life cycle stage status: See [Life-cycle value pairs](https://www.servicenow.com/docs/ZBykUoots2EfsNPjqCpY8A#foundation-domain__section-life-cycle-states).
{#foundation-domain__ul_g5z_dnh_4tb}
## CSDM videos in the ServiceNow Community {#foundation-domain__section_d13_nlx_mwb}
[Playlist of all CSDM videos](https://www.youtube.com/playlist?list=PLkGSnjw5y2U7QNr9jL6TAgwQvYBI_LEtK)
*[\>]: and then