Setting Actual Start and End Date

Raymond Coates
Tera Contributor

I know there are a lot of posts about the Actual Start and End Date on a project task but I'm not sure how to get things working the way I need.

 

What I would like is when a project task is moved to Work in Progress the actual start date is set to the current date and time.  Correspondingly when the project task is closed the actual end date is set to the current date and time.

 

I see the ubiquitous scenario of the actual start and end dates being set to the planned start and end dates.

 

Derive time component from planned dates is unchecked.

 

How can I get the behaviour that I am looking for?

15 REPLIES 15

@Ankur Bawiskar , thank you for taking the time to reply.  I think it was putting the puzzle pieces together from the various artifacts I found that was my struggle.  Further, coupled with the documentation from ServiceNow, and the behaviour I was seeing in the PDI, things were not making sense on how to proceed.

 

Based on @Namita Mishra's reply there might be something worth exploring regarding observed vs expected behaviour in an OOB instance.

Anand2799
Tera Guru

Hi @Raymond Coates ,

 

You can disable the OOB client script "Populate Actual Dates on State Change" which is updating actual start date and actual end date onChange of state to planned start date and planned end date.

Now, you can create your own client script based on your requirement, refer code shared by AshishKM.

Anand2799_0-1758871993646.png

Consider testing it based on different schedules, time zones and allow dates outside schedule field.

 

Thanks

Anand

@ Anand2799, thank you kind sir, I think your piece in combination with the code @AshishKM  is the missing link I wasn't able to put together.  I was looking at the OOB client script but figured it had to be re-written.  Disabling the OOB client script and creating a separate business rule for the desired behaviour is probably the safer approach in this case.

 

Before I proceed with this, I am curious to learn more about expected OOB behaviour mentioned by @Namita Mishra.

 

EDIT 1: Corrected reference to tejas1111, I referenced the wrong person.

EDIT 2: Or, maybe I did reference the right person. Too early in the morning. (coffee)

In reviewing the solution as described in the linked article it has an interesting piece:

 

Enable firing of Business Rules on save from Planning Console

 

We have that currently disabled, and it is specific to the old Planning Console.  We are using the Project Workspace (New), so it won't trigger the Business Rules based on that property.

 

Further there is a significant performance impact when enabling this property for the Planning Console, so even if we did use the old Planning Console it would not be a great user experience.

 

Enabling this property will resolve the issue of deleted project tasks not showing in the Audit Deleted Records table, however, with us using the Project Workspace (New) it doesn't recognize this property, and deleted records will not show in the Audit Deleted Records table.

 

If that property is required for the business rules to trigger, I think we will have to explore the client script approach.