Benefits of preparing the data in the Foundation stage

Tables that you work on during the Foundation stage

Business Process table [cmdb_ci_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.

Contract table [ast_contract]

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 table [model_id]

The Product model table [model_id] 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 hardware 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.

CMDB Group table [cmdb_ci_query_based_service]

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.

Location table [cmn_location]

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 follows

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 table [sys_user_group]

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.

User table [sys_user]

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 table [core_company]

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.

Business Unit table [business_unit]

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 table [cmn_department]

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, 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.

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.

Note:

The [life_cycle_control] table uses the type of CI (hardware, document, logical 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 CSDM life-cycle sync between legacy fields and related assets.

The following assets can use life-cycle value pairs:

• Product life cycle
• Hardware life cycle
• Logical life cycle
• Document life cycle
• Location life cycle

Watch the ServiceNow Community video: CSDM V4 product and life cycle discussion