Issues converted to Projects

Hi Jill -- you can create a resolving object column in your views and reports like what we do (shown below) and this not only will show you when there is a resolving project, but also the name of that project and a link to it. This has been critical for us as an organization to know what has been converted, what it connects to, and quick access to it. Matt May Stream Companies

You can also add the column [Resolving Object Type], which shows if the resolvable is a Project (PROJ), Task (TASK), or Issue (OPTASK). We add filters to our reports to filter out all the issues being resolved by Projects (since they are essentially the same request twice in the system, and we're choosing to work it as a project instead of a request). The filter is [Resolving Object Type] is NOT "Proj". You can do the opposite and also only see the issues being resolved by Projects. Vincent Goodwin The Capital Group Companies

As to your second question: No, the issue's [Planned Completion Date] isn't linked to the project's [Planned Completion Date]. There are other fields that remain in-sync when there's linked by Resolved By relationship (such as [Status] - if you change the lead task/issue's [Status], the status on all the "resolvable" tasks/issues get updated too), but not the [Planned Completion Date]. There is an Idea Exchange idea for this though... https://support.workfront.com/hc/en-us/community/posts/115001245447-Option-to-Link-Planned-Completion-Date-of-Issue-to-Planned-Completion-Date-of-Resolving-Object?page=1#community_comment_115001176533 Vincent Goodwin The Capital Group Companies

OMG that's it, Resolving Object & Type. THANK YOU. There are so many fields, I can't quite figure out how to find the ones I want. I search through Help but I never seem to find the article that I'm looking for, I'm sure it's me not using the right terminology. I upvoted the idea to connect the deadlines between Issues and Projects. It's at 23. I hope it can get more votes. Jill Ackerman

One more question on this topic, again, couldn't find it in Help and my Implementation Manager is on vacation. Plus, I have laryngitis so I can't call the Help Desk!! :) Yesterday, Dana submitted a Request. I got the Request and converted it into a Project. The Custom Form from the Request came along into the Project. All is peachy, I assigned people to work on the Tasks and aside from the ridiculous due date with everyone out for the holiday, all is good. Today, Dana went back to her Request and updated the Custom Form because she had new information. Dana saw the Project Name, but since I had renamed it, she didn't know what it was (why would she?!) so ignored it and went straight to the Request Name she recognized. That new information did not migrate to the Custom Form in the Project so nobody working on the Project can see her new and fabulous information. This seems like a real world situation that would happen all the time. How do you manage it? Did we do something wrong? Should I not have renamed her badly named Request? We can all see that they are linked (thanks to the above new column I have in my View!) so that can't be it? Thanks! Jill Ackerman

What you are experiencing is what I refer to as the "Conversion effect". When WF converts an issue to a project it can only transfer the information a single time. So if you change info on the issue after that it will not update the project because the conversion already happened. You could In theory convert the issue to a new project but you will then have to kill the first project. Maybe Eric Lucas or Doug Den Hoed could chime in? Michael Lebowitz Marketing Analyst Michael.Lebowitz@guidewellconnect.com T 904-436-4240 | M 904-200-1364 Fax 904-565-6156 4800 Deerwood Campus Pkwy DCC 800-4-272 Jacksonville, FL 32246

Thanks Michael, Yes, this is a common situation, and I can suggest several ways to deal with it: Overstate : change nothing, but train everyone to avoid the situation by being mindful not to update the original Issue once it has been converted to a Project Overkill : do not preserve the Issue when it's converted: can't incorrectly update what isn't there, so instead, email/call with the info Overshare : do not preserve the Issue when it's converted, but then also grant access to the resulting Project to the originator of the Issue (noting that this can be Too Much Information in many situations) Overcompensate : preserve the Issue, and with some reporting (either Issue vs its Project, or Project iteration of its originating Issues' details via text mode trickery) it might be possible to show discrepancies so they can be manually synchronized Overturn : preserve the Issue, but leverage our UberCalc solution to automatically synchronize such updates from the Issue to the Project (some assembly required)

Jill, there is an Idea Exchange idea to also make it clearer that an issue has converted to a request. https://support.workfront.com/hc/en-us/community/posts/115003984253-Add-an-update-to-the-update-feed-and-have-a-link-in-project-and-request-header-area-when-requests-are-converted-to-projects- We also have a Notes report that filters just for issues that have been converted for projects. We check every other day to see if people are commenting on the original request. Vincent Goodwin The Capital Group Companies

Hi Doug Are you saying that I can delete the Issue after it's converted into a Project with no bad side effects? I love that solution, but I would have never thought to do it, deleting is very scary! It's easy enough to put the Requester onto the Project in some format so they can still have access (I think, need to figure out permissions and access which is another maze but I'm getting there!) Jill Ackerman | Director, Direct Marketing Lindblad Expeditions 96 Morton Street | New York, NY 10014 Ph. 212.261.9080 | Fax. 212.265-3770 jilla@expeditions.com | "http://www.expeditions.com/"> www.expeditions.com

Hi Jill, As attached (from Setup > Project Preferences > Tasks and Issues), Workfront is designed to let you choose whether or not to keep the original Issue when it gets converted to a Project (or Task), and can even add the Primary Contact to the Project automatically. I've found this approach works well where the conversion is effectively an "escalation" as it simplifies Workflow to consider the Project to BE the Issue, but now graduated into a Project, and (of course) it's ok for the Issue submitter to have access to the Project. Conversely, where the latter is NOT desired, it's likely wiser to preserve the original Issue and use the Resolving Object features As Designed to relay arms length status back to them as work progresses. Which of those constitutes Bad Side Effects is likely up to the person drinking the medicine.