Fixing Issue Status when Linked Task is Closed In Error and Re-opened

[Kelly_Wehrmann]

Ok, I am curious if anyone else has noticed this, has issues with this, or has a better solution than what we are currently using to mange this. Back in 2012 when we started using Workfront I noticed for Issues that we convert to Tasks (we keep the Issue linked) if the user accidentally changed a Task Status to Complete and then changed it back to In-Progress or some other status, the Issue Status remained Closed. The Issue does not update to reflect the correction on the Task. When I had reached out to the Help Desk they indicated that this was "working as designed"; once the Issue Status is set to Closed it basically ignores any additional status changes on the Task. This creates problems for us because our Issues are using facing and we don't want to be signaling to the requester that something is complete, when it really isn't. So how do we try to manage this? We use an exception report. We have a report that shows the Issue Status and the Task Status and if they do not match, someone has to manually fix the Issue to "reset" the status. This involves going to the Issue, editing the overview tab to save the current value in the Task field, removing the This Resolves value, and saving the change. Then editing the Issue a second time to set This Resolves to Task and pasting the Task name back in the field, and saving it again. In my opinion....a lot of work when it would be more efficient is the system was able to handle it and I wish I knew why it didn't (....it's the little things....). I opened an Idea on the Exchange over a year ago (03/14/17) and it hasn't received much support. Another mystery... As of today the vote count is up to 6. Am I missing something here? Is there a better way to handle this in a more automated fashion, without having to resort to an API? The integrity of information that we have available to our end users is especially important, so I'd like to make this as seamless as possible without all the manual work. If you have a better mouse-trap please share! :) "https://support.workfront.com/hc/en-us/community/posts/115005868768-Ability-for-System-to-Automatically-Maintain-Status-on-Issue-if-Resolving-Task-Project-Completed-Prematurely?flash_digest=c41d7b1e5b1d7f9e867083ad8a52955a18ba9daf&page=1">ABILITY FOR SYSTEM TO AUTOMATICALLY MAINTAIN STATUS ON ISSUE IF RESOLVING TASK/PROJECT COMPLETED PREMATURELY Admin Kelly-Wehrmann SSFCU

[Doug_Den_Hoed__AtAppStore]

Hi Kelly, I had another idea on this one (untested), but will take no offence if it seems no better than the Devil You Know: Create a new Status called "Closed Pending Final Confirmation" based on Current Change your process to use that value instead of "Closed" to avoid tipping off the Issue Originator (just yet) Create a report to review such items carefully and confirm that they are indeed ready to be Closed If you made a mistake, simply roll back the status (e.g. to In Progress) without having to unwind the Resolved By info If all is clear, change the Status to Closed, and in turn, alert the Issue Originator Come to think of it, you could probably accomplish the same effect by using an Approval -- same concept. And if none of the above suits you, yes, you could at least automate your current workaround using the API, or Fusion, or our "http://store.atappstore.com/product/ubercalc/">UberCalc solution. Regards, Doug Doug Den Hoed - AtAppStore Got Skills? Lend a hand! https://community.workfront.com/participate/unanswered-threads

[VicAl]

I upvoted your Idea. Hopefully others here will too. It's a valid change that should be made. In the meantime Doug had a good option. I'll add one more option and then you can choose your poison �� . You can consider converting the Issue to a Task and letting it delete the Issue. WF is smart enough to know the Task is now the former Issue and changes that link for the Submitter (in their Requests I've Submitted tab) and it brings over all the documents and updates etc. But you lose the Primary Contact field and thus the automatic email to the Primary Contact when the Status changes. We add the Primary Contact to the Description of the Task so we know who requested it (we do use the API to do this, but it can obviously be done manually). And then we have to comment and tag the primary contact when we want to let them know we're working on it, etc. For us, we made this decision to manually make our folks send a communication, because we had a problem with our staff not communicating with the requestor. So this forces them to (kinda – we still have to view reports to ensure it's being done �� ). So I doubt that's better, but it's another option. And hopefully your idea gets the votes it needs.

[Kelly_Wehrmann]

Thanks for sharing these options! :) I'll have to investigate each to see which will work best for our implementation. We keep the Issue so that we can have that as an open line of communication with the Requester. We do not give them access to the Task. We use the task for our back office collaboration (basically the sausage making that no one really wants to see)! You guys are AWESOME! Thanks again! Admin Kelly-Wehrmann SSFCU