u_lead_time

[Mary35]

how can you preserve the lead time when a change record is rejected? 

[Community Alums]

Hi @Mary35 ,

Preserving lead time when a Change record is rejected requires careful handling of the change process and associated dates. Here's a breakdown of strategies:

1. Reinstating the Original Schedule:

• Custom Fields: The most straightforward approach is to create custom fields on the Change record to store the original planned start and end dates. When a Change is rejected, a Business Rule can copy these original dates back into the standard start/end date fields.
• Workflow: Within your Change Management workflow, have a specific path for rejected Changes. In this path, before the Change is closed, trigger the Business Rule to restore the original dates from the custom fields.

2. Utilizing the Change Schedule:

• Change Schedule Table: ServiceNow has a change_schedule table. If you're using this table to manage your Change schedule, you can maintain the original schedule even if the Change is rejected.
• Rejection Workflow: When a Change is rejected, the workflow can update the change_schedule record to reflect a "planned" or "pending" status, even though the Change itself is closed. When a new Change request is created (perhaps a corrected version), it can then refer to this existing schedule entry.

3. Change Request Linking:

• Related Lists: When a Change is rejected, use the "Related Lists" functionality to create a link to a new Change request that will replace the rejected one.
• Copy Data: When creating the new Change, have a Business Rule copy over relevant information from the rejected Change, including the original planned start and end dates. This helps maintain context and avoids re-entering data.

4. Automated Date Adjustments:

• Business Rule (Complex): You could create a Business Rule that, upon rejection, calculates a new lead time based on the rejection date and the original lead time. This is more complex as it requires date/time calculations and assumes the lead time remains constant. This is less ideal as lead times are rarely constant.
• Workflow Integration: Integrate this logic into the Change workflow so that the new dates are automatically populated on the Change record.

5. Reporting and Metrics:

• Reporting: Ensure your Change Management reports can track lead times, including those for rejected Changes. This allows you to analyze how rejections impact overall lead times and identify areas for improvement.

Preserving lead time when a Change record is rejected requires careful handling of the change process and associated dates. Here's a breakdown of strategies:

1. Reinstating the Original Schedule:

• Custom Fields: The most straightforward approach is to create custom fields on the Change record to store the original planned start and end dates. When a Change is rejected, a Business Rule can copy these original dates back into the standard start/end date fields.
• Workflow: Within your Change Management workflow, have a specific path for rejected Changes. In this path, before the Change is closed, trigger the Business Rule to restore the original dates from the custom fields.

2. Utilizing the Change Schedule:

• Change Schedule Table: ServiceNow has a change_schedule table. If you're using this table to manage your Change schedule, you can maintain the original schedule even if the Change is rejected.
• Rejection Workflow: When a Change is rejected, the workflow can update the change_schedule record to reflect a "planned" or "pending" status, even though the Change itself is closed. When a new Change request is created (perhaps a corrected version), it can then refer to this existing schedule entry.

3. Change Request Linking:

• Related Lists: When a Change is rejected, use the "Related Lists" functionality to create a link to a new Change request that will replace the rejected one.
• Copy Data: When creating the new Change, have a Business Rule copy over relevant information from the rejected Change, including the original planned start and end dates. This helps maintain context and avoids re-entering data.

4. Automated Date Adjustments:

• Business Rule (Complex): You could create a Business Rule that, upon rejection, calculates a new lead time based on the rejection date and the original lead time. This is more complex as it requires date/time calculations and assumes the lead time remains constant. This is less ideal as lead times are rarely constant.
• Workflow Integration: Integrate this logic into the Change workflow so that the new dates are automatically populated on the Change record.

5. Reporting and Metrics:

• Reporting: Ensure your Change Management reports can track lead times, including those for rejected Changes. This allows you to analyze how rejections impact overall lead times and identify areas for improvement.

Example Business Rule (Reinstating Original Schedule):

(function executeRule(current, previous /*null when async*/) {

    if (current.state.changesTo('closed') && current.state.is('closed') && current.approval == 'rejected') { // Check if Change is rejected

        // Copy original dates back to the Change record
        current.start_date = current.u_original_start_date; // 'u_original_start_date' is your custom field
        current.end_date = current.u_original_end_date;   // 'u_original_end_date' is your custom field

        // Optionally, add a comment to the Change record
        current.comments = 'Original schedule reinstated due to rejection.';

        current.update(); // Update the Change record
    }

})(current, previous);

Key Considerations:

• Custom Fields: Using custom fields to store the original dates is the simplest and most recommended approach.
• Workflow Integration: Integrate your date handling logic into the Change Management workflow for automation.
• User Experience: Make it clear to users why the dates are being reinstated and how the new Change request relates to the rejected one.
• Reporting: Track lead times for rejected Changes to identify patterns and improve the change process.

thank You ....!

[Dr Atul G- LNG]

Hi @Mary35 

The lead time started when a change gets created, so even if a change gets rejected, you can preserve that.

[Mary35]

We are looking for the Planned Start date to be the target to meet the Request Approval date in order to meet the lead time. 

Normal change lead times and approvals are determined by the risk of the change.

Low Risk • Lead time – 24 Hours (1Day)

ModerateRisk • Leadtime-48Hours(2Days) 

HighRisk • Leadtime–72Hours(3Days) 

[Dr Atul G- LNG]

Hi @Mary35 

You can create a client script and compare the change create date with the risk date ( as you defined), and if it is less, show an error message to the user.

https://www.servicenow.com/community/itsm-articles/change-management-lead-times/ta-p/2299624