Apologies if this has been asked before. Is it possible to have a Task within a project that we could "Convert to an Issue" that would go into another teams Queue, as well as keep the connection intact so status rolls upwards? | Community
Skip to main content
terry70825
terry70825
Level 2
August 27, 2020
Question

Apologies if this has been asked before. Is it possible to have a Task within a project that we could "Convert to an Issue" that would go into another teams Queue, as well as keep the connection intact so status rolls upwards?

  • August 27, 2020
  • 1 reply
  • 745 views

The use case for this:

Team A is responsible for building performance reports.

  • Team A has a request queue to intake requests from stakeholders like "Please build a report about XYZ"
  • Team A will convert that request to a project, retaining the original issue as how the stakeholder stays up to date, and creating a full project with the broad steps SCOPE -> DESIGN -> GET DATA -> BUILD.
  • The GET DATA step in particular, requires work to be done by another team.

Team B manages all data requests and is the team that would actually go GET DATA.

  • Team B has it's own request queue to intake requests from stakeholders like "Please get the data for XYZ".
  • Team B would most likely convert their own request into a full project as well with steps that might look like SCOPE -> INGEST -> TRANSFORM -> QA.

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.

    This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

    1 reply

    K
    Community Advisor
    KatherineLaCommunity Advisor
    Community Advisor
    August 28, 2020

    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

    terry70825
    terry70825Author
    Level 2
    September 1, 2020

    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.

    K
    Community Advisor
    KatherineLaCommunity Advisor
    Community Advisor
    September 1, 2020

    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.

    1. On a Custom Form at a Task level, you could create a Typeahead field for a 'Project' dropdown with a filter set to show only projects with a status of 'Queue'. The end result there would be a reportable field, but it wouldn't really DO anything. If you were to view the Queue project itself, this wouldn't result in an Issue in that project.
    2. Within a Project, you could raise an Issue there and assign it to that team which would accomplish the goal of having an Issue assigned to them, though still not in their own independent project-queue.
    3. If they REALLY have a business-case for having it in their own specific project-queue, you could then 'move' the issue from the originating project into the actual queue. The only link remaining at that point would be a note in the Update section saying 'moved this from'.
      1. Though at this point, you could use a Custom Form field to allow them to link it back to the originating project.

    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

    Terms & ConditionsAccessibility statement

    Loading footer...