Life cycle mapping form
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.
Fields on the Life cycle mapping form
| Field | Description |
|---|---|
| Mapping for table | Legacy
CMDB table and descending tables that this mapping applies to. Applies to a descending table unless there is a mapping configured specifically to the descending table. |
| Priority |
Priority of applying this mapping definition for the table. The Priority value on the life cycle mapping table is used when a record update triggers the “legacy-to-life-cycle” synchronization, and multiple legacy value states on the record match with mapping rules. Of the multiple values, the highest priority (lowest numerical value) entry is used to set the life-cycle value pairs. If the highest priority entry can't be used, the system uses the next record in priority. Note:
Priority is not used if Reverse synchronization is active because there should be a maximum of one reverse-synchronize choice for each life-cycle value per class. |
| Active |
Denotes whether to apply this mapping definition. Deactivation results in lower-priority mappings being used or setting standard life cycle fields to TBD. |
| Legacy field name | Legacy field in the specified Mapping for table that is currently being used to store a life cycle stage. The value should be used as the source for the life cycle mapping. |
| Legacy subfield name | Value to set if the Legacy field name has a subfield. For example, if hardware Status has a substatus, then specify the name of the substatus here. |
| Legacy field value | Legacy value in the specified Mapping for table that is currently being used store life cycle stage. The value should be used as the source for the life cycle mapping. |
| Legacy subfield value | Value that is set if the Legacy field value has a subfield. For example, if hardware Status has a substatus, then specify the value of the substatus here. |
| Life cycle control | Class and life cycle stage and life cycle stage status that are used as the authoritative source of valid combinations for life cycle mapping. |
| Table | Standard object table that the Life cycle control belongs to. |
| Life cycle stage |
Standard life cycle stage to map the specified Legacy field value to. Note:
The Life cycle control setting determines that this particular life cycle stage is appropriate for the mapping. If there is no match in the life_cycle_mapping table, the value is set to TBD. |
| Life cycle stage status |
Standard life cycle stage status to map the specified Legacy field value to. Note:
The Life cycle control setting determines that this particular life cycle stage status is appropriate for the mapping. If there is no match in the life_cycle_mapping table, the value is set to TBD. |
Life Cycle Stage inheritance for Business Application records
Business Application records define a restricted set of Life Cycle Stage values that are intended to reflect application planning and usage, such as Ideation, Design, Operational, and End of Life. These life cycle definitions are configured using the life_cycle_control table specifically for the cmdb_ci_business_application class. When you view or edit a Business Application record, however, additional Life Cycle Stage values such as Deploy and Inventory might also appear. These stages are not defined directly for Business Application, but are inherited from parent CI classes (for example, cmdb_ci) through the aggregation-based inheritance model that is used by life_cycle_control. In this model, life cycle definitions from the current CI class are combined with life cycle definitions from all parent classes in the CMDB class hierarchy. Child classes therefore extend parent life cycle definitions rather than overriding them. As a result, Business Application records can display Life Cycle Stage values that are applicable to infrastructure or hardware CIs but might not be semantically meaningful for applications. This behavior is expected and working as designed.
In contrast, in sys_choice inheritance definitions in child tables override the values in parent tables.