The use case for this:
Team A is responsible for building performance reports.
Team B manages all data requests and is the team that would actually go GET DATA.
So I know how to connect Issue A -> Project A and Issue B -> Project B. But is there anyway to connect Project A: Task 3 -> Issue B so that the resolution of that task is dependent on the other team finishing the request in their queue (which ultimately would be tied to their own corresponding project)
Or maybe another idea would be could one embed some other teams project as a set of tasks within a larger project? Maybe this is another use case for the Parent/Child Projects idea out there. Or maybe a feature request to allow Convert Task to Issue and maintain the Resolve Object.
Topics help categorize Community content and increase your ability to discover relevant content.
Hi Terry,
In that scenario, I would have Team A create 'Main Project 123' by converting the original Issue from their queue. A task within Project 123 could be assigned to Team B, and leverage a task-version of the same intake form used in their normal queue to ensure all the right information to complete the task is submitted to Team B. Team B could then create Sub-Project 456 to manage their own timeline.
From there, leverage the cross-project predecessor features to ensure the completion of Project 456 is linked back to Project 123.
This (I think) would also ensure the timeline for Project 123 included the effect of the sub-project and ensure your original stakeholder had a view of the overall timeline. That part I've never specifically tested though.
https://one.workfront.com/s/article/Understanding-Cross-Project-Predecessors-638211475
Katherine
Views
Replies
Total Likes
Thank you! Should Team B be persistent about having their own queue, my team will need to create an issue. So as an alternate approach in this case, is there any way to connect/associate a Project->Task to a Queue Issue? I'm looking for a potential Custom Form Field that would allow me to select from a list of active Queue Items basically.
Views
Replies
Total Likes
I'd start by challenging them on what system functionality/visibility/reason they specifically want their own queue. Once you understand better /why/ they want it, then you can evaluate alternative options from there. Most often, I get 'we want to be able to report on our workload' and I can find easier ways to get the visibility they need without crazy workarounds.
Short version, between some combination of issues/tasks/queues and careful custom form fields, you COULD do what you're describing - but not without setting your teams up for a world of manual manipulation and data entry.
I would be focusing Team B on what part of a 'queue' is so specifically important and seeing if you can get that functionality within the traditional features, honestly.
Katherine
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies
Views
Likes
Replies