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

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. 

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?

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

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.

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.

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.

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.

Hey everyone,

Thanks for upvoting this idea!

I'm marking this idea as "Planned" and it is included in our product roadmap.

At the meantime, please continue adding your use cases here so that we can have more background for solution design.

Thanks,

Upvoted! If form isn't completely blank carry it over to the resolving object. Better yet, custom forms should be made agnostic to a record.. just like custom fields are agnostic to forms. Why have multiple copies of the same darn form for main objects when you can just have one.

It is difficult to maintain forms when you have to always do two to make sure they match. I can understand that some people might want more information on the Project form (we don't), but it would be nice if you can have the option for it to copy or not.