Actual End Date not being set

[brianlan25]

We change our Normal and Emergency workflow in the following ways.

1. Change tasks are created when you request approval

2. The workflow will move to review state when the tasks are closed.

Issue: 

We found a couple changes were the actual end date was not set. I was able to reproduce this by closing the change task before clicking on the UI Action Implement. When looking at the history of the change it goes from Scheduled to Review and every time it does not set the actual end date. Any idea why the out of the box BR (Change Model: Set work end) would not set the actual end date in this case? 

The BR have very simple condition model is (normal, emergency, or standard) and state changes to review. So just because it is moving from Scheduled to Review I'm not sure why it would not run as the state is still changing to review.

[kmohammed]

Hi,

This is happening because your customized workflow is bypassing the path that sets work_end — not because the Review state itself is wrong.

How it works out of the box: the (Change Model: Set work end) logic belongs to the Change Model's state transition handling. It is designed to fire on the normal Implement -> Review transition — i.e., when a change that has actually been implemented is moved into Review. In your reproduction there is no Implement step at all: the history shows Scheduled -> Review. The change never went through the transition the model expects, and the state change is being driven by your workflow when the last task closes, not by the user taking the change through Implement -> Review.

A quick way to confirm this on your instance: take a test change and move it Scheduled -> Implement -> Review using the UI actions — work_end is set. Then take another and close its tasks from Scheduled so the workflow jumps it straight to Review — work_end stays empty. Same target state, different path, different result. You can also check your affected changes for work_start — changes that skipped Implement often have the same class of problem at the start of implementation.

Your options, in order of preference:

1. Stop the skip (best). Do not let the workflow move the change to Review before it has been implemented. Gate the workflow's move-to-Review step on the change having passed through Implement (for example, only progress when the change state is Implement), or prevent task closure from advancing the change while it is still Scheduled. This keeps the model transitions, work_start/work_end, and state history consistent.

2. Set the field where you bypass the model. Since your workflow is what moves Scheduled -> Review, add the work_end setting to that step of your workflow (set Actual end date to the current date/time at the moment the workflow transitions the change to Review). Do not edit the OOTB business rule — put the logic in the custom path that created the exception.

3. Backfill the existing bad data separately. For the changes already in Review/Closed with an empty Actual end date, populate work_end from the close/Review entry in the record history as a one-off data fix, so reporting on those changes is not permanently wrong.

I would not add a second standalone business rule on "state changes to Review" — you would end up with two competing owners for the same field, and it still would not fix the underlying problem that changes are reaching Review without ever being implemented.