---
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 stage
# CSDM implementation stage --- Foundation {#ariaid-title1}
* Freigeben Version: Australia
*
* Aktualisiert 12. März 2026
*
*  6 Minuten Lesedauer
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.
## Benefits of preparing the data in the Foundation stage {#csdm-implement-foundation-stage__section_b5y_5ph_jwb}
The basis of any good data model is the foundational data that is referenced throughout the model.
* The base-system tables in the CMDB act as the foundation for many ServiceNow AI Platform products.
* The tables help your organization align with reporting requirements early to expedite the value you get from ServiceNow AI Platform products. You can reduce or eliminate costly rework tasks needed to align with reporting requirements.
{#csdm-implement-foundation-stage__ul_ndp_zfr_qmb}
## Tables that you work on during the Foundation stage {#csdm-implement-foundation-stage__section_rcq_fx4_wnb}
Business Process \[cmdb_ci_business_process\] table
: 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.
Contract \[ast_contract\] table
: The Contract table identifies binding agreements between two parties. When you populate services provided by vendors into the CMDB, consider the role that contracts play when evaluating service level agreements (SLAs).
Product model \[model_id\] table
: The Product model \[model_id\] table identifies the unique types of products your organization develops or consumes. When you group assets and CIs by product model, you unify and relate CIs that are part of the same digital
product and portfolios of products. Grouping assets and CIs by product model can help you plan projects, monitor costs, and rationalize your data. Discovery can populate tangible/physical product models after they're
operational, but other types of product models require planning from product owners.
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. 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.").
CMDB Group \[cmdb_ci_query_based_service\] table
: The CMDB Group table identifies a collection of CIs based on the results of saved Query Builder queries, encoded queries, or manual entries.
CMDB groups are critical elements of dynamic CI groups and the strategic management of CIs. Decide early how you want to report CI information and how you want to monitor CIs. These
decisions affect how you create CMDB groups. For Change and Incident processes, there are two distinct impact analysis behaviors for dynamic CI groups. See [Matching the usage of dynamic CI groups to service type](https://servicenow-prod.fluidtopics.net/1rJGzpXgWC0rkCPVVgWhZA "The type of service determines how you use dynamic CI groups.").
Software bills of material (SBOM)
: An SBOM is the overall collection of components of a piece of software. Cyclone DX is supported.
Location \[cmn_location\] table{#csdm-implement-foundation-stage__dlentry-location-table}
: The Location table uniquely identifies geographic locations. You can create a hierarchy of location data using the Parent attribute. The hierarchy might include entries that match your reporting
requirements. For example, you could populate the location table as followsAbbildung : 1. Your organization's location attributes
To include more detail in reports, you could extend the Location table to include floors, rooms, and even datacenters. With hierarchy capabilities, trusted source data, and your requirements in hand, you can create
locations that support your future reporting needs.
Group \[sys_user_group\] table
: The Group table identifies sets of users that share a common purpose. Groups may perform tasks such as approving change requests, resolving incidents, receiving email notifications, or performing work order tasks. Groups also
use the referential data in the CMDB to identify how CIs are managed (for example, the Managed by Group) and supported (for example, the Support Group). Any business rules, assignment rules, system roles, or attributes
that refer to a group automatically apply to all group members.
Hinweis:
The Managed by Group setting identifies the group that manages a CI class (ensuring that it is complete and correct). It might or might not be the same group as repairs an individual CI.
User \[sys_user\] table
: The User table identifies the persons and applications that have access to your ServiceNow instance. You can organize users into groups that are associated with the Company, Business Unit, and Department tables.
Organizational structure
: Organization structure tables identify internal business structures and external customers, manufacturers, and vendors.
Company \[core_company\] table
:
The Company table is populated with the legal entities of companies. Entities can be either internal (your organization) or external. You can use the Parent attribute to build a hierarchy. Consider the legal entities that you need for reporting when the CMDB is populated.
* Internal entries should focus on a hierarchy of legal entities rather than a hierarchy of business units within a legal entity.
* External entries are identified by a True or False flag. The Customer flag identifies your external customers. The Manufacturer flag identifies companies that create products that you consume. An internal
organization might be a manufacturer.
* The Vendor flag identifies organizations that provide products that you purchase. An internal organization might be a vendor.
{#csdm-implement-foundation-stage__ul_b4m_fsh_jwb}
Business Unit \[business_unit\] table
: The hierarchy of your business is populated in the Business Unit table with a reference to the parent company. A business unit is a part of your organization that is responsible for specific operations, such as finance,
human resources (HR), or IT. A hierarchy within a business unit is common. For large multinational organizations, you might have business units that identify independent regional operations and the specific operations
within the region.
Department \[cmn_department\] table
: The Department table includes a finer level of detail about a business unit. The Department table gives you another way to categorize users, groups, assets, and
CIs.
Life cycle tables
: CSDM
life-cycle value pairs track the life cycles for products, assets, contracts, CIs, locations, and other objects. Using the standard values consistently helps you to 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.
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, for example from inception or procurement to operation and then perhaps to end of life.
* life cycle stage status is the particular status of a CI within its current life cycle stage.
{#csdm-implement-foundation-stage__ul_xkz_15s_lrb}For example, a tangible/physical CI in the Operational stage might change stage status over time from In Use to In Maintenance to End of Support. A different tangible/physical CI might go from In Use to End of Support without ever having been in In Maintenance status.
Hinweis:
The \[life_cycle_control\] table uses the type of CI (tangible/physical, document and contract, location and so on) to determine which life cycle stage status values are available for each life cycle stage.
To take full advantage of the CSDM life-cycle standards, you can map legacy status data to the life-cycle value pairs. See [Enabling life-cycle sync from legacy-to-asset](https://servicenow-prod.fluidtopics.net/1DuB3hVTxLksjzgSPoqhFw#csdm-life-cycle-standard-values "You can align life-cycle values for each product instance on the asset, CI, and IBI tables. A one-time process moves legacy status values for asset and CI across the platform to standard CSDM life-cycle value pairs (life cycle stage and life cycle stage status). Business rules then run regularly to ensure identical IBI, asset, and CI life-cycle data for each product instance.").
The following assets can use 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.")
{#csdm-implement-foundation-stage__ul_h1q_3hg_4tb}
Watch the ServiceNow Community video: [CSDM V4 product and life cycle discussion](https://www.youtube.com/watch?v=TfRv1VTRsgM)