Custom Form Carry Over When Converting from Issue to Task/Project

[#1]

It would be nice if we didn't have to create 3 copies of each forms, so that when a form is filled out during a queue, the data in the form automatically carries over when the issue it creates is converted to a task or project. Currently, we have to create 3 versions (issue/task/project) of each form, and then the supervisor doing the conversion/assignment of an issue to a staff member, has to ensure they are adding the task or project version of the form when they convert that issue and assign the task, so that the data the person input during the queue process isn't lost.

[#2]

I think it would be incredibly helpful if whatever custom form is filled out in the request automatically pulls through to the project, and to still have the option to add/remove forms as needed. Having a person manually select the appropriate forms leaves way too much room for error and lost information.

[#3]

We'd like the ability to map certain fields of the Custom Form to the Description field on the Project so when it converts, the information we want to show in the Description is pulled in from those form fields. That would reduce the number of times people assigned work on the incoming project have to tab around to find the request information in the Custom Forms location.

[#4]

At least Issue-to-Project you can use templates to pick-up the appropriate custom forms; granted, picking the wrong template is always an issue.

However, converting an Issue to a Task means the process is entirely manual.

Our use case that cropped-up recently and has become more and more prevalent:

Our issue (request) queue is set-up to automate both routing the issue to the correct team, but also sending the requester to the correct forms.

Our issue "forms" are actually a collection of multiple custom forms, creating a library of modules we can choose from. So for example, three of the custom forms are common across most requests, but one or two of them change depending on the request.

For issue-to-project, templates at least serve as a way to make sure that most of the time, if the proper template is used, then the form data is preserved.

With conversions to tasks, the headache is then twofold:

1. I have the have this entire library in duplicate now (issue, project). But more users are converting issues into tasks on existing projects, so there is a call to have task versions of all forms (so now my entire library of custom forms would need to be managed in triplicate).
   1. Training a user to "write down the details of the issue forms in use, and make sure to manually select those same ones when converting to task"...well you can see how viable that isn't. :-(

Having a custom form would cut down on some of the headaches, at least when the custom form is exactly the same across objects (issue/project/task).

I do see an issue where calculation fields or certain other fields still have to change depending on the object, and not sure if there will be a way around this issue of if we'd still be stuck with multiple versions to accommodate slight changes between reference objects.

[#5]

We would also have a lot of use for this feature, in our case it would be document level forms we'd like to copy the information from to project or task level.

[#6]

I imagine this would also help reporting so we could identify the primary contact on a request when doing a report on projects.

[#7]

Has this issue been resolved? I'm trying to convert Issue's to Tasks and keep the data in our custom forms - when I select the form in the task it needs me to re enter all the information...Is there a way to carry over issue custom form details to a task when it's converted?

[#8]

I can't find any way to keep the description field - we can obviously remove it but we can't then accept email requests because Fusion will remove any details.