Copying Form Field Values to Jira Fields Using Automation

[Pankaj Mahajan]

Hello Everyone ,

I recently came across a requirement that I believe many of you may have encountered as well. While Atlassian’s documentation is comprehensive and well maintained, I wanted to share my approach here and get feedback from the community on how it could be improved.

The requirement was to copy values from multiple fields submitted via a form into a Jira field (in this case, the Description field).

In addition, I needed to apply an if–else condition:

• If a user provides a value for a field, that value should be copied to the Jira field

• If a user leaves a field empty, the Jira field should display “No value provided” instead. ( I figured it out that this will be the scenerio only in case of the Non-Mandatory fields).

Below is the approach I followed using Jira Automation and smart values. I’d be interested to hear if there’s a more efficient or cleaner way to handle this scenario.

As usual, I went through several Atlassian documentation pages related to using smart values in automation.

1. Copying field values using smart values

I used an automation rule with the Create Issue Trigger & Edit issue action on the Description field and smart values to copy the required field values.
This part was fairly straightforward and worked as expected.

2. Implementing the If / Else condition

The main challenge arose when implementing the if–else logic.

I reviewed multiple documentation examples, but the usage of the Else condition was not very clear especially for cases where field values might be empty or not exist at all (this was particularly true for User Picker fields, where an empty value does not always return a result).

To work around this, I used two separate If conditions:

• The first condition checks whether the field is empty or does not exist

• The second condition checks whether the field has a value, and if so, copies that value into the target Jira field

While this approach works, I’m curious if there’s a cleaner or more optimized way to handle this logic.

3. Copying attachments

I also attempted multiple approaches to copy attachments using automation, but none of them worked as expected.
Eventually, the Atlassian Support chatbot confirmed that copying attachments is currently not supported.That said, I’m still open to suggestions if anyone has found an alternative or workaround for this requirement.

Below are the smart values I used.

Smart Values and conditions : 

* *What type of support* : {{issue.customfield_17513}}

* *Question or request* : {{issue.customfield_17452}}

* *System / Tool / Process* : {{issue.customfield_12670}}

* *Checked existing resources* : {{issue.customfield_17453}}

* *Urgency* : {{issue.customfield_17451}}

* *Manager* : {{#if(not(exists(issue.manager)))}}No Value Provided{{/}}{{#if(not(issue.manager.isEmpty))}}{{issue.manager.displayName}}{{/}}

* *Supporting Links* : {{#if(issue.customField_17716.isEmpty)}}No Value Provided{{/}}{{#if(not(issue.customField_17716.isEmpty))}}{{customField_17716}}{{/}}

* *Attachments* : Unable to determine a workable solution using Jira Automation.

While the solution is functional, there may be opportunities to optimize the conditional logic or reduce the overall complexity of the automation rule. I welcome any suggestions from the community on improving or simplifying this approach.

Thanks!!

[Rudy Holtkamp]

Hi @Pankaj Mahajan ,
I think you can do this more easily. Instead of:

Manager
{{#if(not(exists(issue.manager)))}}No Value Provided{{/}}{{#if(not(issue.manager.isEmpty))}}{{issue.manager.displayName}}{{/}}

You can also use

{{issue.manager|"No Value Provided"}}

If you have a smart value, and use a | (pipe-character) you can give it a default value. 

[Pankaj Mahajan]

Hello @Rudy Holtkamp ,

Thank you for the suggestion, it worked perfectly and also helped me understand the usage of the pipe-character.

I used the value you suggested, with a small modification. Instead of using

{{issue.manager|"No Value Provided"}}

I updated it slightly to retrieve the manager’s display name, as I needed the name instead of the ID.

{{issue.manager.displayName|"No Value Provided"}}

Thank you !!

[Bill Sheboy]

Hi @Pankaj Mahajan 

Yes, and...to the suggestions from @Rudy Holtkamp -- The short answer is experimentation and testing are required to handle the absence of data for smart values.

There are several types of fields and smart values, and different types handle "emptiness" in different ways.  And...even when a field is defined as a specific type it may present as a different type for automation smart values.  For example, the advanced roadmap fields which are Date type will arrive as Text type in smart values.  Plus, we need to consider smart values which are loaded just-in-time, thus there may be racetrack timing challenges when testing for emptiness.

While the default value handling with a pipe character helps in many cases, it does not consistently help with lists, nested lists, empty versus null strings, just-in-time values, etc.  Experimentation is required.  A helpful technique is to force a smart value's value to text, and then use either the default value handling or test on the length() of the text string.

Kind regards,
Bill

[Pankaj Mahajan]

Hello @Bill Sheboy ,

Yes, that aligns with what I’ve been seeing as well. The way different field types and smart values handle “empty” can vary quite a bit, so some trial and error is pretty much unavoidable. The examples you mentioned around lists, nested lists, null vs empty strings, and just-in-time values explain why there isn’t a single solution that works everywhere.

Forcing the smart value to text and then checking a default value or using a length() or using two if conditions check has been working better for me in cases where the pipe default doesn’t behave consistently. We’ll just need to test this per field .

Thanks!!

Regards,

Pankaj

[Jonas Pencke]

Hey @Pankaj Mahajan ,

@Rudy Holtkamp already gave you a good hint for simplifying the logic part by using a so called fallback or default value.

However, looking at the coping attachment section here is some help:

• Your observation and findings align with what we've seen as well.
• But we found two practical workarounds that can make attachment copying work reliably in Cloud.

1. Add a short delay before closing / cloning

Form attachments in JSM are synchronized asynchronously in the backend and not immediately available on the issue. According to Atlassian this synchronization can take up to ~6 seconds.

If your automation clones or transitions the issue immediately after submission, the attachments may simply not be there yet.

What worked for us:

• Add a Delay action (7–8 seconds) just before the “Close Issue”, “Clone Issue”, or similar final step.

• This gives the backend enough time to finish synchronizing the attachments before the clone happens.

It’s not very elegant (because you always pay the delay), but it’s simple and often sufficient. 

2. Use a second automation triggered by the relation / link

Instead of copying attachments in the same automation that creates or links the issue:

• Create a second automation rule that is triggered by:

  • the issue link being created, or

  • a specific field update, or

  • any other reliable post-creation event.

• Make sure to enable: “Allow rule trigger from other rules.”

• This second rule only:

  • edits the issue, and

  • copies the attachments.

For us, attachment copying works reliably in this second step (because by then the attachments are already present on the source issue). If needed, you can still add a very small delay at the start of the second rule. 

In short:

• The limitation is real, but mostly a timing / async backend issue, not a hard functional block.

• Either give the system a bit of time (delay), or decouple the logic into two steps.

Maybe that helps 😊

BR,

Jonas

[Pankaj Mahajan]

Hello @Jonas Pencke ,

Thank you for sharing your valuable insights.

I tried both of the suggested approaches; however, neither worked for my specific use case.

My requirement is to copy data from certain fields submitted through forms and populate all those values in the Description field, along with any attachments.

It appears that smart values currently do not support copying or embedding attachments into the Description field. Even when attempting to run a separate automation to copy attachments, it ends up overriding the values populated by the first automation. This occurs despite using smart values to retain the initially submitted Description content before introducing a delay.

That said, I truly appreciate you taking the time to share your suggestions and insights.

Thanks!!

[Pankaj Mahajan]

Hello @Jonas Pencke ,

Thank you for sharing your valuable insights.

I tried both of the suggested approaches, however neither worked for my specific use case.

My requirement is to copy data from certain fields submitted through forms and populate all those values in the Description field, along with any attachments.

Not sure but it appears that smart values currently do not support copying or embedding attachments into the Description field. Even when attempting to run a separate automation to copy attachments, it ends up overriding the values populated by the first automation. This occurs despite using smart values to retain the initially submitted Description content before introducing a delay.

That said, I truly appreciate you taking the time to share your suggestions and insights.

Thanks!!

[Jonas Pencke]

Hi @Pankaj Mahajan ,

thanks for the clarification — a few important points here.

1) What do you mean by “embedding attachments into the Description”?

Description cannot contain attachments. It’s a text / rich-text field only.

Attachments can be copied to the issue, and they can be referenced or listed in Description, but they cannot be embedded inside it. So if that’s the expectation, that part is unfortunately not supported.

2) Writing multiple field values into Description should work.

If values are being overwritten, that’s most likely a race condition between automations, not a functional limitation.

To avoid that:

• Make sure only one rule edits Description, or that rules are clearly chained.

• Allow one rule to trigger another if you chain them.

• Append to {{issue.description}} instead of overwriting it.

• Use “Re-fetch work item data” at the start of the second rule if it depends on updates from the first one.

3) A simple example or screenshot would help a lot to see exactly what you want to achieve and have a shared starting point.

We should be able to help you with the problem. 😊

Best,

Jonas

[Pankaj Mahajan]

Hello @Jonas Pencke ,

The actual requirement was to embed the screenshot directly inside the description field along with the other field values. I understand this isn’t ideal, especially since we have dedicated attachment fields specifically meant for uploading files.

Since it’s not possible to include attachments within the description field, we should now be all set.

Thanks!!

Regards,

Pankaj

[Devlend Maul]

We had something similar with an additional requirement of gathering, transforming, and inputting multiple "form only" field data into a Jira field. This was accomplished by using a Send web request action to the Get form index api to fetch the id of the attached form and then a Send web request to the Get form simplified answers api to get the form field values. Then using Advanced branching, looped through the form fields that we wanted, pulled the values, and structured them into the Jira field.

[Greg D]

You may want to look into added advanced branching to your automation rules to check each value that you care about having an answer, store each as a variable of both its question and answer if it has an answer and then set your description to all of the variables in order so that it only shows the responses. It doesn't say "No value provided" in that case, but probably would be even better since you can then search for work items by the question terms to know which ones have that answer. But depends on the why behind this for if it is even recommended.

Then for attachments, there may be some options if they are actually storing as attachments on the work item (you can manipulate them with smart values in automation as noted here: https://support.atlassian.com/cloud-automation/docs/jira-smart-values-issues/ ). Or in some cases if you need the attachment to be a trigger and you also need to see internal attachments on a JSM work item, you can utilize a system webhook for when attachments are added and then ping an incoming webhook in Jira automation to control logic around what happens next if you want.

Updated all of this as per my conversation with Rudy in replies to this. You can grab form values with smart values in automation now after you set the form field key on each field in the form settings and that will be better than needing to call the API endpoints  - described here in this community post.

The Forms API was the previous option to drive logic in Jira automation, also allowing you to capture values that aren't synced to Jira fields. Will leave the details in case there is another use-case.

Using the Forms API:

You can make a GET request to:

https://api.atlassian.com/jira/forms/cloud/<YourSiteId>/issue/{{issue.key}}/form/{{issue.properties."proforma.forms".forms.uuid}}/format/answers

This returns form answers that you can reference in your automation rule as:

• {{webResponse.body.get(0).answer}}

• {{webResponse.body.get(1).answer}}

• {{webResponse.body.get(2).answer}}, etc.

As you were seeing, you can use these smart values and API values in IF conditions to check if they're empty or match certain criteria, then dynamically build your description. You could either create different descriptions based on each match, or build variables via IF statements and combine them all in the description.

A word of caution:

I usually recommend not syncing everything from forms to the description...

• The form is already attached to the work item and can be expanded when needed
• Best practice: Sync only the most valuable piece to the description (such as one main "what" question), while keeping supplemental questions in the form itself. This ensures stakeholders provide critical information without cluttering your work item
• Only sync additional fields if they're absolutely necessary for reporting/metrics
• Working directly from form details keeps things cleaner and avoids field bloat (where there aren't already 1-to-1 field matches that track the same type of value globally, the form handles both intake and context for action) 

Hopefully in the future, Rovo will be able to read form values directly, or automation will improve with form actions so we don't need custom API calls.

[Rudy Holtkamp]

Hi @Pankaj Mahajan , @Greg D ,

I would recommend not to use Greg's suggestion anymore. The smart values are now easier to access and without the use of an authorization token (which is going to expire within a year). 

In all automations you can use

{{issue.forms.<form_id>.last.<form_field_key>}}

see this documentation. 

A few things to note here:

• Every field you want to access, needs a form field key. So if you don't have them yet in your form, add them asap.
• Fields from older created forms (without the form field keys) can't be accessed this way. In other words, if you add a form field key now, it does not apply to already created forms
• Lastly some field types (like select fields or date fields) need an extra attribute e.g. label or .format("yyyy-MM-dd"), see the previous doc link

[Greg D]

Good call @Rudy Holtkamp ! I forgot about the newer smart values when looking back at one of our rules (looks like we still need to clean some of those up.... I think when I first saw that launch, I saw we needed to get those form field keys and it turned into a project we couldn't yet prioritize, ha).

I guess my points still remain with how I was suggesting that you can utilize IF statements in the automation rule to check for empty values or build your logic in a few different ways. Once you have the form field key added everywhere needed, I'm not sure if there is a quicker way to set up "only grab both the questions and answers where there is a value in the answers" and then copy all of that in one fell swoop (not sure if you are aware of anything similar).

I still think it is best to not copy the form values at all if you can avoid it (at least not as an entire duplication of the form again into a single field since you have the details from the form available to unfurl in the exact form format)... I see value in grabbing some form values into dynamic messaging and using logic on particular responses to drive different workflow behavior, but it seems like many people prefer to just copy all of the information based on familiarity of using the description (and maybe to empower long-standing integrations with the system fields).

[Rudy Holtkamp]

I still think it is best to not copy the form values at all if you can avoid it

I certainly agree to this. In most case duplication of data is not the best way to go forward. However if you have a JSM form, then it can only be viewed by the requester (and request participants) and the agents. I see a few scenario's where you want to create a linked issue with the data from the JSM form. So in that case it would make sense to copy the form data to another field. 

[Greg D]

For sure. There are definitely valid use-cases. In the one you mentioned, you can also copy the form itself to another work item as an option (although things have gotten a little funky with the Forms/Advanced Forms). Forms help tremendously with avoiding bespoke field bloat and so they are super powerful!

Hoping we can add them to other create screens/transition screens on the internal side and get to feature parity between the basic and advanced/JSM. The basic forms have gotten better and only they allow open submission onto a software work item directly like an evolved issue collector, but more formatting options and not needing custom fields makes the advanced/JSM forms still needed on the software side too.