Context - JIRA software projects do not have forms available, so I'm using a JIRA Business Project to allow internal teams to submit a form for project requests that then translate into tasks within the business project. My end goal is to then take those form submissions (recognized as tasks) and move them to our day-to-day software project.
Issue - there are several custom fields on the form that do not map to fields on tasks within our software project, nor do we want them to. I need to retain the data from the form without compromising our software project fields.
Proposed solution - I'd like to take all of the custom fields on the business project form and, upon submission, have the OOB task description filled out with the inputs from the custom fields. This would allow me to preserve the information gathered in the form and still move the issue to the software project to work on once we've accepted the request without the need to create a ton of new fields in our software project that don't translate to our dev team.
How do I post multiple custom field values to the standard description without one custom field value overwriting the other? If anyone has any other solutions/workarounds outside of my ask please let me know!
Welcome to the Atlassian Community!
This is not the best of designs for a Jira process. Moving an issue should only be done for housekeeping or "genuinely just raised it in the wrong place" cases.
Moving an issue is a horrid thing to try to do in Jira because it is structural. You have already explained it yourself in the second paragraph of the question! Moving an issue requires that you deal with all the configuration that might be different between the old and new project or even issue type. You don't want to have all the business project's fields in the target, so you are going to have to destroy the data in them or write code that can tell Jira to drop them during the move.
It would be far easier to duplicate the issues into the target project, copying all the fields you want to keep, and doing exactly what you suggest - adding the source fields as plain text to the Description (or a dedicated text field). I would also link the two issues together so that you can easily find the one at the other end from either, and easily automate "hey, the developers have done this with their issue, update something on the source"! There's even a "create linked issue" in some types of project that does most of that!
On the duplicate custom fields overwriting, that should not be a problem. Fields are all unique - if you have cf_10030, cf_10081, and cf_10191 in your source issues (those numbers are the underlying IDs of customfields in the database), even if all three of them have the same name, they're separate fields, and your automation can say things like
Set the Description on the new issue to the source issues fields:
Description current value +
cf_10030 <name of field>:<value> +
cf_10081 <name of field>:<value> +
cf_10191 <name of field>:<value>
I'd pad that with line breaks, or make them bullets or something to pretty them up, the code there will copy the description and then blurt out all your fields on one line, but I wanted to keep the concept simple.
This can be done with automation and smart values. To post multiple smart values in the description fields you just have to list them, something like this:
{{issue.summary}}
{{issue.mycustomfield1}}
{{issue.mycustomfield2}}
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Here is an example of how I do it for off-boarding requests, this one is creating a task for a team in their project with the information that they need:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.