CMDB Calculation

NarasimhaRC
Tera Contributor
Hi Community,

 

We have an Application Service that is marked Operational Status = Retired and the related Business Application is Decommissioned. However, Service Availability Results are still being generated.

 

The active record appears to be in service_offering_commitment, where the Availability commitment is still mapped to either the Configuration Item or Service Offering.

 

Deleting the Service Offering Commitment stops the calculation, but we do not want to delete the record because we need to preserve historical/audit data.

 

On the service_offering_commitment form, we have:
- Status Field with choices Active and Decommission
- End Date
- Last Reviewed Date
- Configuration Item
- Service offering
- Service commitment

 

Our proposed approach is:
1. Set Status Field = Decommission
2. Populate End Date
3. Preserve original CI/Service Offering in custom audit fields
4. If Availability still calculates, clear the active Configuration Item / Service offering mapping after preserving the original values
5. Automate this through Flow Designer when Application Service = Retired or Business Application = Decommissioned

 

Questions:
1. Does OOTB Availability calculation honor Status Field = Decommission or End Date on service_offering_commitment?
2. Is there an OOTB way to retire/deactivate a Service Offering Commitment without deleting it?
3. Is clearing the CI/Service Offering mapping after preserving values in custom fields acceptable?
4. Can CMDB Data Manager help with this, or does this require custom Flow/Business Rule logic?

 

Looking for the best-practice CSDM-aligned approach.
Thanks!
1 ACCEPTED SOLUTION

vaishali231
Kilo Sage

Hey @NarasimhaRC 

In this case, I would not recommend deleting the service_offering_commitment record, because that removes useful historical context.

From an OOTB behavior perspective, Availability commitments are used by Service Portfolio Management to generate availability records for the mapped Service Offering or Application Service. The documentation states that when an Availability commitment is added, availability records are generated and updated based on outages, and a daily job generates the commitment availability reports. For Application Services, the mapping is through the cmdb_ci field on service_offering_commitment.

Answers to your questions:

  1. Status = Decommission / End Date
    OOTB, I would not assume that the Availability calculator automatically stops only because the custom/status field is set to Decommission or because End Date is populated, unless your version/configuration specifically has logic checking those fields. The key driver is still the active commitment mapping to the CI or Service Offering.
  2. OOTB retire/deactivate option
    There is no commonly used OOTB “deactivate but retain history” action like deleting the commitment. Best practice is to end-date/decommission the commitment record and ensure it is no longer considered by the calculation logic.
  3. Clearing CI / Service Offering mapping
    Yes, this is acceptable if done carefully. Preserve the original CI / Service Offering in audit/reference fields first, then clear the active mapping only when the service is retired/decommissioned. This prevents future calculation while retaining historical traceability.
  4. CMDB Data Manager
    CMDB Data Manager can help govern CI lifecycle activities, but it will not usually handle this specific Service Portfolio Management commitment calculation cleanup by itself. You will likely need Flow Designer or a Business Rule to update the related service_offering_commitment records when the Application Service becomes Retired or the Business Application becomes Decommissioned.

Recommended approach:

Set commitment Status = Decommission

Populate End Date / Last Reviewed Date

Preserve original CI / Service Offering values in audit fields

Clear the active CI / Service Offering mapping if availability still generates

Automate through Flow Designer or Business Rule

Test in sub-prod and confirm no new availability results are generated after the next daily availability job

This keeps the solution CSDM-aligned because the retired Application Service / decommissioned Business Application is no longer actively contributing to operational availability reporting, while historical commitment data is still retained.

 

*************************************************************************************************************************************

If this response helps, please mark it as Accept as Solution and Helpful.

Doing so helps others in the community and encourages me to keep contributing.

Regards

Vaishali Singh

Servicenow Developer
Linkedin - https://www.linkedin.com/in/vaishali-singh-2273361bb



View solution in original post

1 REPLY 1

vaishali231
Kilo Sage

Hey @NarasimhaRC 

In this case, I would not recommend deleting the service_offering_commitment record, because that removes useful historical context.

From an OOTB behavior perspective, Availability commitments are used by Service Portfolio Management to generate availability records for the mapped Service Offering or Application Service. The documentation states that when an Availability commitment is added, availability records are generated and updated based on outages, and a daily job generates the commitment availability reports. For Application Services, the mapping is through the cmdb_ci field on service_offering_commitment.

Answers to your questions:

  1. Status = Decommission / End Date
    OOTB, I would not assume that the Availability calculator automatically stops only because the custom/status field is set to Decommission or because End Date is populated, unless your version/configuration specifically has logic checking those fields. The key driver is still the active commitment mapping to the CI or Service Offering.
  2. OOTB retire/deactivate option
    There is no commonly used OOTB “deactivate but retain history” action like deleting the commitment. Best practice is to end-date/decommission the commitment record and ensure it is no longer considered by the calculation logic.
  3. Clearing CI / Service Offering mapping
    Yes, this is acceptable if done carefully. Preserve the original CI / Service Offering in audit/reference fields first, then clear the active mapping only when the service is retired/decommissioned. This prevents future calculation while retaining historical traceability.
  4. CMDB Data Manager
    CMDB Data Manager can help govern CI lifecycle activities, but it will not usually handle this specific Service Portfolio Management commitment calculation cleanup by itself. You will likely need Flow Designer or a Business Rule to update the related service_offering_commitment records when the Application Service becomes Retired or the Business Application becomes Decommissioned.

Recommended approach:

Set commitment Status = Decommission

Populate End Date / Last Reviewed Date

Preserve original CI / Service Offering values in audit fields

Clear the active CI / Service Offering mapping if availability still generates

Automate through Flow Designer or Business Rule

Test in sub-prod and confirm no new availability results are generated after the next daily availability job

This keeps the solution CSDM-aligned because the retired Application Service / decommissioned Business Application is no longer actively contributing to operational availability reporting, while historical commitment data is still retained.

 

*************************************************************************************************************************************

If this response helps, please mark it as Accept as Solution and Helpful.

Doing so helps others in the community and encourages me to keep contributing.

Regards

Vaishali Singh

Servicenow Developer
Linkedin - https://www.linkedin.com/in/vaishali-singh-2273361bb