Converting an Issue to a Task in a Request Queue but I need it to Live within a Different Project (not the queue)

[J_Hobbs]

We are having trouble getting users to convert issues into tasks then assign the task to a different destination project rather than keeping the task in the request queue project.

The ideal process would have them converting the issue/request into a task and then choosing what project to have the task moved into. The problem is the default/preselected project for the "Select Destination Project*" field is the request queue and it is getting overlooked because the field is already populated.

It would be helpful if that Select Destination Project field was NOT pre-populated, and users had to select where the task would live upon conversion.

Anyone else have this as a problem they have delt with in the past?  

[J_Hobbs]

Or if we could limit the ability for people to add tasks to my "Queue Projects" that could solve this as well.

[Stacey_Robertson]

If you automate the process of converting the issue to the task using Fusion, then you could have Fusion move it to the correct project.

[J_Hobbs]

We don't currently user Fusion but to complicate matters more, the converted issues wouldn't all be going into the same project as a new task. The task could be attributed to a number of different projects based on the ask.

[skyehansen]

I think it's a reasonable ask, so you should consider submitting this as an idea ( https://experienceleaguecommunities.adobe.com/t5/workfront-ideas/idb-p/workfront-ideas ).

Aside from this, there are a number of workarounds you might consider.

If the project truly should not be used for tasks, you could check the project Access section (edit the project and scroll down) -- you might find there's a way to give Manage access to the request but simply View access to the project and thereby prevent them from adding the task to begin with. Definitely test this functionality... occasionally you'll be blocked because it turns out that the user really does need contribute or manage access to the project for some reason.

If changing access doesn't work, I usually favor a default task custom form on this project with a nice big section heading for "PLEASE MOVE THIS TASK TO ANOTHER PROJECT, NOT THIS ONE" followed up by a couple of required checkbox fields, such as "please tick this box to indicate that you understood" and "if you understood, why didn't you just change the project name instead of ticking the first checkbox?"

[CalvinFold]

Can you elaborate on the issue?

Is it that users are not trained or knowledgable enough to convert a Request into a Task on an existing project?

My Project Managers (planners) may not like Workfront, and find it confusing at times, but even they are hyper aware that a request must be converted to a new project or a task on an existing project.

(Mind you, I agree that there should be an option to not allow conversions to the "Request Project" itself. I think WF needs a special "Queue" object that doesn't have all the project baggage and has a single purpose: to hold requests. I'm just trying to figure out why anyone working with requests would not make the assignment to an existing project intuitively. I've seen alot of goofy mistakes and behavior in our couple of years with WF, but this is one they've rarely made.)

[J_Hobbs]

Hi Calvin, thanks for taking the time to reply. It has been my experience that users would like to do the least amount possible to process object actions within Workfront.

If a required field is already pre-populated chances are it is going to be overlooked or ignored by a user who won't choose for the task to be moved to a new project.

If the Select Destination Project field would stay blank they this would not be an issue. Workfront should not assume that we want to convert an issue into a task and have it live in the queue project.