Best thoughts on converting multiple requests into a project, without losing the data on each individual request?

[Roz22]

We currently utilize issues as 'request queues' that ladder to larger projects. We ideally would love to house multiple projects under one project, as they may come in at different times. The team would love for that to be all in one spot, rather than under a program. Does anyone have suggestions on how to accomplish this without manually adding the newly converted issue's custom form information manually and without it automatically replacing the existing information? Ideally needing both. 

[skyehansen]

If I'm reading this correctly, most customers set this up as a shell project, and keep all related issues in this project. There are a number of ways (views and dashboards related) to then make it easy to reference the converted projects. e.g. in your shell project, you could set up a view in your issues tab so that folks can see a link to each converted project.

[Roz22]

Hi Skye! So we convert most requests/issues into tasks or projects, and we don't keep the issues after conversion. Would keeping the issues be a way to keep that data? I inherited this instance so it's not set up how I would always have it as defaults, but can help tell the why as to if we should change practices. The ask is for multiple projects to live under one project shell. From a marketing lens, think larger campaign with many deliverables. Thanks! 

[skyehansen]

keeping the originating issues, is one way to "group" everything in one place. So instead of using a program and projects, you are using an umbrella/shell project and issues that will link you to converted projects. As for defaults... that's up to you. I think you can set it up as a group preference if this work is all being done by a particular group. 

Our marketing campaigns work in exactly this way. A program can contain a number of marketing campaigns (each campaign represented by a project). Each campaign would list "channel" requests, think web deliverables, social, print, etc. These requests stay in the campaign project so a campaign manager can see what requests pertain to their project. There is a link to the converted project if the campaign manager needs to "travel" to the downstream project to see what is going on. Historically, a campaign manager can also always go back to last year's campaign to see what deliverables were requested. And so on.

[Lyndsy-Denk]

I see that you don't keep your issues, so this might not be something you can quickly adopt without changing that model:

You can tell each issue to be resolved by the same project. You do this by manually resolving.

[J_Mas]

You could try something like this:

• Create one "Default" project (this would be your main project "shell" or "parent" project).
• When a new issue/request comes in through your queue, choose the 3 dots, then "Convert to task".
• 
• In the "Select Destination Project" field, choose your default/parent project.
• 

This should create a new task in your parent project with the same name as your issue/request. The important part here is to make sure that any of your custom forms from the issue, are also setup with an Object Type of "Task". (i.e. When you're in Setup - Custom Forms, select your custom form, and make sure that "Task" is listed in the Object Types menu).

As long as your custom form has an Object Type of Task, it should carry-over all of the data captured during intake, and add it to the new task.

You can then add additional workflow subtasks under your new "project task" within the parent project.

The trickiest part of all of this comes in when you go to report. You'd need to report at the task-level (or assignment-level) since your task is technically your project.

Anyway, this is probably a little messy, but maybe it'll give you some ideas.