Expand my Community achievements bar.

Ability for System to Automatically Maintain Status on Issue if Resolving Task/Project Completed Prematurely

Avatar

Level 10

3/14/17

We have an ongoing issue that requires exception monitoring for our Issue/Request Queues. Incoming Issues/Requests are converted to Tasks/Projects so that they can be scheduled/assigned to resources within our IT department. The Issue/Request is left intact and is used as the communication vehicle between IT and the person that submitted the request (thus insulting the requester from the behind the scenes "sausage making").

One problem that we have found is that if someone in IT clicks the Done button vs. the Done with My Part, the Task is marked Complete and it has a trickle down effect of marking the Issue/Request Complete; which under normal circumstances is ideal when they really intend to change the Task status to complete. However, if the Task is marked complete by mistake, once the IT resource realizes changes the Task Status back to In Progress, the Issue/Request is no longer updated. As a result, the linked Issue (that the Task resolves) is no longer reflects the correct state of the Task. Once the Issue/Request gets set to Complete, its like it cuts off all communication with the Task that resolves it and the statuses between the 2 (Issue and Task) are out of syn, which is not good. We have to have additional exception reporting to identify when the issue status is not the same as the resolving task status. Once these out-of-sync items are identified, a manual process it needed to update the Issue to remove the "Resolved By" contents on the Issue Over tab and then the object type and name of the object (resolving task) back to the Issue. This essentially forces the Status of the Issue to be reset back to the corresponding value of the Task so that they are once again talking to each other, at least until the Task status is updated to complete.

This was reported to Workfront as a bug a few years back, but it was reported as working "as designed". However, I don't think the one-and-done design is very good. I'd like the vendor to clean up this process and other similar ones that result in a lot of overhead and manual processed to monitor the integrity of the data. Yes, you have to monitor data integrity in any system to have good reporting, however, things that can be addressed as a function of the system should be incorporated into the tool to reduce manual overhead and maintenance so we can focus on the more qualitative aspects of data integrity.

2 Comments

Avatar

Level 2

11/20/17

I have this issue as well. I understand why the resolving object would match the issue, however, once we change the status BACK to current/in progress, the issue should follow suit or at the very least, give the system admin the option to change it.

Blocking system admins from changing the status on issues is frankly unacceptable. (the only workaround is to de-associate the issue+project, change the issue status, then re-associate the issue+project. This is not a realistic process to follow)

Avatar

Level 10

10/15/18

This one was created some time ago... Is anyone else having issues with this, or noticed that this happens? Just curious. Thanks!