Can I create a Jira field with associated sub-fields?

[Kevin Goohs]

A portal form is collecting multiple field information.  Ultimately, this leads to a released version that will be available for deployment.

When a deployment request is made, I would like 4 other fields automatically added to the deployment request ticket based on the release version selected.  

[Trudy Claspill · Accepted solution]

Hello @Kevin Goohs 

Welcome to the Atlassian community.

When you say you want 4 other fields added, do you mean made visible to the person filling out the deployment request so that they can select values for those additional fields?

Or do you mean you want the 4 fields to be populated automatically with data after the request is created?

If you want the fields populated with data that can be done with an Automation Rule.

If you want the fields to be displayed conditionally to the person completing the request that requires a different solution which depends on the type of Space this concerns - Software, Service, or Business. And if it is Service, it also depends on if you want the fields shown to a user completing the request through the customer portal, or an internal user completing the request through the internal Jira/JSM UI.

[Kevin Goohs]

Hello @Trudy Claspill 

Thank you!

I want the 4 fields to be populated automatically.

[Trudy Claspill]

Then you should be able to do that with an Automation Rule.

Are you familiar with Automation Rule functionality?

https://support.atlassian.com/cloud-automation/docs/jira-cloud-automation/

There are several courses available as free, on-demand training through the Learning link at the top of the community pages. Here is a search to get you started.

https://community.atlassian.com/learning/catalog?product=Jira%2CJira+Service+Management&search=automation

If you are not familiar with the features you may want to reduce the search to items at the Beginner level.

[Kevin Goohs]

I am familiar with Jira Automation and use it extensively.  I will follow-up w/in the Learning link.  Thank you

[Trudy Claspill]

Let us know if you come up with more questions.

There are two basic scenarios to consider for automation:

1. When the deployment request is created and release version is provided
2. When the release version is changed in an existing deployment request

Other things to consider:

1. Does the field you are using for release version ever have multiple values?
2. What do you want to do with the dependent fields if the release version is cleared?
3. If "release version" is a reference to a Version in the project, do changes need to be made to the 4 fields if data within that Version is changed?
4. Is "release version" set manually or through automated processes (automation rules, workflows, integrations)? That could impact your rule structure.
5. Is it possible to change a work item type from another type to a deployment request, or from a deployment request to another work item type? Should that have any impact on the 4 fields?

[Kevin Goohs]

Hi @Trudy Claspill - been busy.

The basic scenario I'd like to reference is:

1. When the deployment request is created and release version is provided

Here are the responses to your questions:\

1. Does the field you are using for release version ever have multiple values? NO
2. What do you want to do with the dependent fields if the release version is cleared? CLEAR THEM AS WELL
3. If "release version" is a reference to a Version in the project, do changes need to be made to the 4 fields if data within that Version is changed?  NO.  OMCE THIS IS TRIGGERED, THE VALUES WILL NEVER CHANGE.
4. Is "release version" set manually or through automated processes (automation rules, workflows, integrations)? That could impact your rule structure. MANUALLY ENTERED ONTO A FORM.  AUDITED.  When the ticket is transitioned to the "released" workflow status, all values are locked in.  
5. Is it possible to change a work item type from another type to a deployment request, or from a deployment request to another work item type? Should that have any impact on the 4 fields?  no.  we manage these separately

[Trudy Claspill]

Hello @Kevin Goohs 

What type of field are you using for "release version"? 

Do you already know how to get the data to put in the four fields, if it isn't static data?

Do you need additional advice on how to construct the rules? Or are you planning to work on it and then ask questions if necessary?

[Kevin Goohs]

Hello @Trudy Claspill 

"release version" is a "Select List (multiple choices)" custom jira field.

Let's cut this down to two fields now:

• Release Version and  
• QA Approver

Both fields are included on a request management intake form.

• Release version - The customer enters a name into a Short text field on the intake form which is linked to a jira custom field called Candidate  This is presented in the ticket as Release Verison Name.  However, it has not been added to the available Release Version custom field.  This is done manually after we completed the workflow steps.
• QA Approver - The customer enters a name into a QA Approver field, which is a linked Jira field for Request Participants. This is then presented in the ticket as Request Participants, which is fine.

We have two projects, REL (for release candidate requests) and DEP (to request a deployment of an officially released version.

The latest goal: When a customer selects from the available list of release versions in a DEP ticket, we would like the QA Approver (Requested participant) who was listed on the respective REL ticket to be automatically on the DEP ticket. 

I have reverted to the team using a jira filter that is a quick manual lookup for them. 

If you have any advice, it's always appreciated.  Thank you.

Kindest regards,

Kevin

[Kevin Goohs]

Hi @Trudy Claspill 

One other thing I am trying to do. 

When the ticket is placed in the Released status, how do I automatically append the Release version custom field with the value entered in the Candidate field?  

I do not want to lose the long list of released versions that exist there.  

We are trying to avoid the manual step.

[Kevin Goohs]

{
  "fields": {
    "customfield_Candidate": [
      { "value": "{{issue.customfield_ReleaseVersion}}" }
    ]
  }
}

but this tells me that the Candidate Value is not in the Release Version custom field list.

[Trudy Claspill]

Hello @Kevin Goohs 

I have not had a chance to read through your replies and formulate a response. However I can speak to a problem with your JSON code.

To reference a field you use either the visible field name (i.e. Candidate or Release Version) or you use its unique custom field ID (i.e. customfield_#####)

customefield_fieldName is not a valid way to reference the field.

You might try this:

{
  "fields": {
    "Candidate": [
      { "value": "{{issue.Release Version}}" }
    ]
  }
}

If there is a space in the field name for "Release Version" there should be a space when you put it into the JSON code.

[Kevin Goohs]

Goal Automatically copy the value from a Release Version field (customfield_11707) into a Candidate multi-select list field (customfield_10341) whenever a Jira work item transitions to "Released" — using a Jira Automation rule.

---

Problem Statement The target field (customfield_10341) is a select list that only accepts pre-approved values. Since release names are constantly growing and varied, the allowed values list can't be maintained manually — it needs to be updated dynamically by the automation itself before writing the value.

---

Obstacles We Hit

1. Wrong smart value syntax — initially used "value": "customfield_11706" (a hardcoded string) instead of a smart value to read the field dynamically.
2. Wrong field ID — customfield_11706 was returning empty; the correct source field was customfield_11707.
3. Missing .value path — needed to determine whether the source field required {{issue.customfield_11707}} or {{issue.customfield_11707.value}} depending on field type.
4. Value not in allowed list — even once the smart value resolved correctly, AAA was rejected because it wasn't a pre-approved option in the target select list.
5. OAuth authentication blocking the API — attempted to use a Jira REST API call via "Send web request" to dynamically add new options to the field, but the Jira instance at dexcare.atlassian.net requires OAuth rather than Basic auth with an API token — blocking every attempt.
6. Labels field not available on JIRA forms — pivoted to a Labels field to avoid the pre-approved list requirement, but discovered Labels fields don't render as a selection option on JIRA forms, making it unsuitable.

[Trudy Claspill]

Thank you for that very clear description! That is really helpful.

Let us break the problem down to 2 parts:

1. Assuming the text from text field Release Version (customfield_11707) has already been added as a value to the multi-select field Candidate (customfield_10341), you are looking for the correct syntax to use to make sure the value from Release Version has been selected in Candidate. Is that correct? And you don't want that process to de-select any of the values that are already selected in Candidate, correct?
2. It would be ideal if you can have automation to check the value of Release Version against the available values for Candidate, and add the value to the available values for Candidate if it is not. Is that correct?

Addressing #1: Update Candidate to also have the value selected that matches the value in Release Version.

According to this documentation the correct syntax would be:

{  
  "update": {  
    "customfield_10341": [{  
      "add": { "value": "{{issue.customfield_11707}}" }  
    }] 
  } 
} 

I have tested this in my own environment and it works in a Company Managed project. This syntax will

• select another already available option in the Candidate field if the value in the Release Version field matches the name of an option in the Candidate field.
• It will not deselect any previously selected values. 
• If the text in Release Version does not match the name of an option already available in Candidate then the rule will fail in the Edit action.

I'll have to spend some more time considering if Automation can be used to add to the available options in the Candidate field. I'll get back to you on that.

[Trudy Claspill]

I should add the above solution assumes that the Edit action is within the context that the multi-select custom field being updated and the short text field being referenced are in the same issue.

I also note that the problem statement in your last update does not match the problem statements in your previous response:

When a customer selects from the available list of release versions in a DEP ticket, we would like the QA Approver (Requested participant) who was listed on the respective REL ticket to be automatically on the DEP ticket. 

[Kevin Goohs]

Hi Trudy,

Yes, I've moved this conversation around quite a bit.

I created a simple Jira filter for the team to reference so they can associate a QA Approver to the selected Release to be deployed.  I thought I could generate and append to a lookup table, but I saw there was a limitation of 20 entries for a lookup table.  

[Kevin Goohs]

regarding your point:

• If the text in Release Version does not match the name of an option already available in Candidate then the rule will fail in the Edit action.

This is exactly my problem.  When I transition a ticket to the Released workflow status, I want the Candidate value added to the Released Version list of values.

I began using Claude.ai yesterday and it continued to bring me to the strategy of OAuth authentication and a webrequest.  

[Trudy Claspill]

So far I haven't found a way to use OAuth with the Send Web Request action in Automation Rules when calling a Jira API endpoint. I found a 2022 change request about it:

https://jira.atlassian.com/browse/AUTO-4

If you learn of a method, I hope you will share what you discover.