Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Copying Form Field Values to Jira Fields Using Automation

Pankaj Mahajan
Contributor
January 7, 2026

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!!

2 comments

Comment

Log in or Sign up to comment
Rudy Holtkamp
Community Champion
January 8, 2026

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

Like # people like this
Pankaj Mahajan
Contributor
January 8, 2026

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 !!

Like # people like this
Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Champions.
January 8, 2026

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

Jonas Pencke
Contributor
January 8, 2026

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

Like Anne Saunders likes this
Pankaj Mahajan
Contributor
January 8, 2026

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
Contributor
January 8, 2026

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!!

Like Anne Saunders likes this
Jonas Pencke
Contributor
January 8, 2026

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

TAGS
AUG Leaders

Atlassian Community Events