How does the sc_task.work_start field get populated

[adrianps]

(Some background) I've been asked to create a report that details the tasks worked by analysts over the past week.  To do this I'm creating a report that pulls data from metric instance records.

In order for metric instance records to be created, I'm relying on <task>.updated events triggering the creation of the instance records.

Which brings me to recording sc_task record activity.

I noticed that the sc_task_events business rule of the sc_task table is conditional on the sc_task.work_start field being populated.

Out of the box, this field is not displayed on the sc_task form and I can't see any obvious way in which this field would get populated.  This would mean that the above business rule would never get executed.

So I'm wondering about the various ways in which I could populate this field and thus trigger the execution of the sc_task_events script:

• Set a default value for the field via the table definition (low preference for this action - I try to avoid altering the database schema).
• Expose the field on the form and require analysts to manually populate it (low preference for this action as I don't know if there is a reason this field is hidden by default).
• Create a business rule or use a workflow to populate a value in this field (this could be viable as it is simply a new record in a table that would commonly hold many created records)
• Delete the criteria from the sc_task_events rule (low preference for this action as I don't know if there is a reason why the business rule is disabled in the absence of a work_start value)

So I guess I'm questioning if there is any reasoning behind the out-of-the-box configuration that apparently disables this event-generating business rule. (Don't want to make an alteration only to have it bite me later).

Any thoughts?

Cheers,

Adrian

[Allen Andreas · Accepted solution]

Hi,

So....you bring up an interesting point. I never really noticed that it was basically "disabled" OOB. After looking in to this further. It seems that this is basically deprecated. Meaning, if you load the notifications for sc_task, the OOB ones, for a split second, you can see the event that would have originally corresponded to this BR triggering and the related event. Such as the sc_task.assigned.to.user event, for the Assigned to notification.

Without touching this BR, I had actually set up my own method for:

1) Populating both the Actual Start (work_start) and Actual End (work_end) fields via BR when the assigned to was actually signed and the task was inactive/state was set to Closed Complete, Skipped, Incomplete, respectively.

2) The OOB notifications were then just set to go off of normal conditions and not actual events firing.

So...there's that and there's how I use it. It's still active in all of my instances, and my PDI and doesn't seem to be causing any issues so that leads me to really think it's just deprecated and instead of removing the BR...they just sort of did away with the events actually doing something.

Please mark reply as Helpful/Correct, if applicable. Thanks!

[adrianps]

For what it's worth:

I've gone with creating a business rule against the sc_task table.  The rule fires before insert when State changes to Work In Progress AND work_start is empty.

The rule runs a script which sets work_start to the current datetime.