--- sourceDocument: Australia ServiceNow AI Platform Capabilities sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/de-DE/servicenow-platform Release : - australia ft:locale : - de-DE ft:publication_title : - Australia ServiceNow AI Platform Capabilities ft:clusterId : - platcap bundleId : - platcap workflow : - Platform --- # Foundation domain # Foundation domain in the CSDM model {#ariaid-title1} * Freigeben Version: Australia * * Aktualisiert 12. März 2026 * * ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 7 Minuten Lesedauer Tables in the Foundation domain contain base data that is referenced from or to objects in the other CSDM domains. Before you can use ServiceNow products, you must populate foundational data. The tables in the Foundation domain aren't used in CMDB relationships. Instead, the tables contain critical referential data. Typical users of the domain are process owners, data stewards, product owners, and contract managers. In the Foundation stage of implementing the CSDM framework, admins prepare the referential data that enables accurate reporting to support good business decisions. Use the base-system tables when you begin implementing the CSDM to derive the highest value from your ServiceNow products and the ServiceNow AI Platform. For more information on this stage of building your CMDB, see [CSDM implementation stage --- Foundation](https://servicenow-prod.fluidtopics.net/UYhFPtlwOu86gXFu_hAW9w "In the Foundation stage of implementing the CSDM framework, admins prepare the referential data that enables accurate reporting to support good business decisions. Use the base-system tables when you begin implementing the CSDM to derive the highest value from your ServiceNow products and the ServiceNow AI Platform."). Hinweis: For an introductory walk-through of the tables and attributes that you should populate for any domain, see the videos listed in [CSDM resources](https://servicenow-prod.fluidtopics.net/qxXXgm6kLWKd4Q8rdAwznw "Resources and videos that complement the documentation."). ## Foundation domain tables used during the service life cycle {#foundation-domain__section_rvc_yqg_5fc} Individual Foundation domain tables are accessed as needed during each phase of the service life cycle. Each topic that describes the life-cycle phase of a domain identifies the foundation tables that are active during that phase. See the following diagrams: * [Tables used during the Ideation \& Strategy phase of the service life cycle](https://servicenow-prod.fluidtopics.net/nHHxOF3LnOE2_z2VaIo4Iw#ideation-strategy-domain__section-idea-strat-active-tables) * [Tables used during the Design \& Planning phase of the service life cycle](https://servicenow-prod.fluidtopics.net/xO8AEXBwxYCkUiUmoN3QLg#design-domain__section-design-plan-active-tables) * [Tables used during the Build \& Integration phase of the service life cycle](https://servicenow-prod.fluidtopics.net/1WDYCn9AwFd25ROTQBmINA#build-domain__section-build-integr-active-tables) * [Tables used during the Service Delivery phase of the service life cycle](https://servicenow-prod.fluidtopics.net/nHmFzwYq1crye_ofymlG0A#manage-tech-servs-domain__section-service-deliv-active-tables) * [Tables used during the Service Consumption phase of the service life cycle](https://servicenow-prod.fluidtopics.net/usj53JvUuxhbDqXWtl9Y1w#sell-consume-domain__section-service-consume-active-tables) {#foundation-domain__ul_vfq_5wf_5fc} ## Data managed by the chief strategist: Value stream {#foundation-domain__section_qpy_bvn_pfc} Value stream: A value stream is the set of actions that take place to add value to a customer from the initial request through realization of value by the customer. The value stream begins with the initial concept, moves through various stages of development and on through delivery and support. A value stream always begins and ends with a customer. The value stream is aligned with your organization's business processes. ## Data managed by the process owner: Business processes {#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=australia&pubname=australia-governance-risk-compliance&ft:locale=en-US) and [Create a business process](https://www.servicenow.com/docs/access?context=create-a-business-process&version=australia&pubname=australia-governance-risk-compliance&ft:locale=en-US). ## Data managed by the contract manager: 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=australia&pubname=australia-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=australia&pubname=australia-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=australia&pubname=australia-it-service-management&ft:locale=en-US). * Service contracts used by Vendor Management Workspace can support tangible/physical 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=australia&pubname=australia-customer-service-management&ft:locale=en-US). {#foundation-domain__ul_mtr_2l1_hwb} For more information, see [Definitions of life-cycle values for document and contract entities](https://servicenow-prod.fluidtopics.net/~ZN2f9QU7yBnIg5gxodVBg "The document and contract life-cycle value pairs represent the overall life cycle of document assets (contracts) and CIs (business process documentation) as related to their products. The life-cycle values for the document and contract life-cycle process are visible only in tables related to document entities in Contracts and CMDB."). ## Data managed by the product owner {#foundation-domain__section_qcy_ydm_rfc} Products and product models{#foundation-domain__dlentry-product-models} : 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). 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. A product model is a specific version or configuration of a product used to manage and track applications on the ServiceNow AI Platform. The Product Model tables are not CIs. CIs reference Product Models using the Model ID attribute (available on all CMDB tables). For example, a Service Offering CI may reference a Service Offering Model, while a Windows Server may reference a Hardware Model. 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. Product Models are recorded in the \[cmdb_model\] table through the following extended tables, known as product model classes. * Application Model \[cmdb_application_product_model\] (version-agnostic) * Software Model \[cmdb_software_product_model\] (version-specific) * Contract Model \[cmdb_contract_product_model\] * Facility Model \[cmdb_facility_product_model\] * Hardware Model \[cmdb_hardware_product_model\] (tangible/physical devices) * Consumable Model \[cmdb_consumable_product_model\] * Service Model \[cmdb_service_product_model\] {#foundation-domain__ul_jmr_wtn_rfc} 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. For recommendations, see [Auto-generate product models for logical CIs](https://servicenow-prod.fluidtopics.net/Yhie9uN_WIv3hIHdMqUiNw "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."). Product features : In digital product release, a feature (what you're developing toward) exists in a particular version of software or service. Software bills of material (SBOMs) : An SBOM is the overall collection of components of a piece of software. Cyclone DX is supported. ## Data managed by the data steward {#foundation-domain__section_vc1_4rn_rfc} CMDB groups : 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 Group \[cmdb_group\] table. * The CMDB group can potentially replace the spreadsheets that you might be using to group your CIs. {#foundation-domain__ul_rrm_prn_rfc} For more information, see [CMDB groups](https://servicenow-prod.fluidtopics.net/d6c5UgXcp9tHQuuOLIU6WA#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."). Locations : 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. {#foundation-domain__ul_srm_prn_rfc} Life-cycle values : 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. 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://servicenow-prod.fluidtopics.net/Lenl5YIwDiZLwNeovHbr2g "Activate the CSDM plugin so you can begin implementing the CSDM data model."). The following processes can use the life-cycle value pairs: * [Life cycle of product entities](https://servicenow-prod.fluidtopics.net/FedW6RmUSd5c8MQL5lZ2pQ "The product life-cycle value pairs represent the overall life cycle of a product model, a specific version, or a product configuration. The life-cycle values for the product life-cycle process are visible only in Product (Models) tables.") * [Life cycle of tangible/physical CIs](https://servicenow-prod.fluidtopics.net/U~drm6FB17vYDTSOGlzQag "The tangible/physical life-cycle states represent the overall life cycle of physical assets and CIs as related to their products. Tangible/physical assets are physical items that are stocked, for example computers, monitors, and keyboards. The stages and statuses for the tangible/physical life-cycle process are visible only in hardware-related tables in Asset Management and the CMDB.") * [Life cycle of intangible/logical entities](https://servicenow-prod.fluidtopics.net/GgoRi~eCCZ5dv56XA5rZBQ "The intangible/logical life-cycle value pairs represent the overall life cycle of logical assets and CIs as related to their products. A logical or software asset includes items like applications, services, and licenses. The life cycle stage and life cycle stage status values of logical items are visible only in tables related to intangible/logical items in Asset Management and the CMDB.") * [Life cycle of document and contract entities](https://servicenow-prod.fluidtopics.net/_w4~bDoBa_czSYSrH2KsUA "The document and contract life-cycle value pairs represent the overall life cycle of document assets (contracts) and CIs (business process documentation) as related to their products. The life-cycle values for the document and contract life-cycle process are visible only in tables related to document entities in Contracts and CMDB.") * [Life cycle of location entities](https://servicenow-prod.fluidtopics.net/q2zR0qWdszptgwI90iFr1Q "The values for the location life-cycle process reflect the locations used by your organization and are visible only in the common data locations table.") {#foundation-domain__ul_trm_prn_rfc} See the ServiceNow Community video: [CSDM V4 product and life cycle discussion](https://www.youtube.com/watch?v=TfRv1VTRsgM) ## Common data managed by the data steward {#foundation-domain__section_tht_5dm_rfc} 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\] and users \[sys_user\]. When the full definition of a CI requires that you identify the contact groups that are associated with the CI, you can add that data in the Teams related list for the CI. {#foundation-domain__ul_ug1_3nn_rfc} 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_vg1_3nn_rfc} ## 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)