Foundation domain in the CSDM framework
Summarize
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 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
astcontracttable. 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
cmdbmodeltable 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
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.
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 and Create a business process.
Contracts
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 module. Contracts are stored in the [ast_contract] table.
- Use the Contract Management application to manage and track contracts. See Contract Management application.
- 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.
- 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.
Products and 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.
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.
CMDB group
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.
For additional information, see CMDB groups.
Life-cycle value pairs
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
- 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.
Legacy status values are auto-updated
- Product Model Status
- Asset State
- Asset Substate
- Contract Status
- CI Install Status
- CI Operational Status
- CI Hardware Status
- CI Hardware Substatus
Map existing status values to CSDM life-cycle value pairs
Use the Life Cycle Mapping module () 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 and Activate align and sync for CSDM life-cycle values.
Common data
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.
- 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?
- Company: [core_company]
- Business unit: [business_unit]
- Department: [cmn_department]
- Location: [cmn_location]
- Groups: [sys_user_group]
- Users: [sys_user]
Location management
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.