CA Service Management

SDM 14.1.05

When a Classic cr workflow task enters "Pending" status, the Actual Start Date (start_date) in detail_cr_wf automatically inserts the current date/time. This is true as soon as the first task in a workflow is created and as each subsequent task transitions from "Wait" to "Pending".

However, when a custom status is used to transition a task from "Wait" to an any site defined custom status, the start_date remains blank. Start date can only be captured if the analyst manually enters it in the task, which does not account for the time it waits to be actioned.

An auto-populated start date is essential to track and report the number of hours an active task waits until it is completed.

How is start_date being added when a task enters "pending" status, and how is it possible to force a start date when a custom status becomes active?

thanks

How are you triggering the status change from 'Wait' to your site-defined status?

The Help Desk selects a custom status on Task 1 to trigger an action macro that assigns Task 2 to one of several possible support groups. This is done manually because location based auto-assignment does not work in Classic WF. Here is an example:

Help desk reviews the request and completes Task 1 to start the WF by selecting a custom status to assign subsequent tasks in the WF to the appropriate region.

For example, "Assign to Group A"

The Action macro on the custom status assigns Task 2 to Group A and flag Task 1 complete. Task 2 is naturally set to Pending status.  However, because a custom status is used in Task 1, Start time in Task 2 is not triggered.

I have confirmed the cause is the custom status by using "Complete" as a status for Task 1 which adds the Start time as expected. Unfortunately, a OOTB statuses do not work when Task 2 has several possible assignee groups.

This is a sample of the action macro to assign all tasks in the WF to the appropriate regional support group:

macro::upd_val("cr_wf", format("cr = '%s' AND sequence IN (20, 200, 40, 400, 70, 700)", cr.persistent_id), 1, 0, "group", "A304829476469547BF028DD12C4B98E6");

Thanks

Jeff

>>> Lindsay_Estabrooks <communityadmin@communities-mail.ca.com> February 20, 2019 15:52 >>>

Lindsay Estabrooks  replied to the discussion

"Re: CR Workflow Task start_date"

To view the discussion, visit: https://communities.ca.com/message/242166460-re-cr-workflow-task-startdate?commentID=242166460&et=watches.email.thread#comment-242166460

Just to clarify my previous ramble... further testing has shown that the issue appears to be related to using a macro to set the next task to an active state in anything other than an OOTB status. To keep the first task active - just in case it needs to go back to the help desk, the task is not marked "completed" and a macro sets the next task to custom "Request Pending" status. This is because SDM does not allow you to force a task into "Pending" status. This is not populating the Start Time.

The potential solution is either to auto-populate a start date from the macro; or to override the ability to force a task into "Pending" status.   

If anyone knows how to accomplish either, that would be appreciated.

Hi Jeffery,

You can reserve the ability to re-assign the first task to restart the process by allowing the 'Reopen' task status for the first task.  Reopen is a variant of 'Pending' that has the effect of resetting all subsequent tasks to 'Reopen-Wait' (which is in turn a variant of 'Wait', which you do not have to explicitly allow) and so effectively restarts the workflow.

You can then allow the out-of-the-box classic workflow to set the first task to Pending, which will set the start date, you can still use a custom status and a status transition 'behavior' to assign the remaining tasks to the required group when the first task goes to one of your custom status values, and you can also allow those custom status values to mark the first task as 'complete'.  And that should mean that the rest of the workflow works as you would expect.  If tasks need to be reassigned, set the 'Reopen' status on the first task and the whole workflow will effectively reset.

Hope that helps,

Regards,

James