Hi Marcelo,

The documentation you linked describes setting the value on a variety of field types.

When a field has multiple options you can address them by ID or Value.

See these examples in the documentation:

• Radio button custom field

• Cascading select custom field

• Multi-select custom field

• Single-select custom field

Edit:

In many field types you do not need to use that structure.
Note the custom field type from Jira and refer to it in the documentation linked.

As an example, I have a 'Select List (single choice)' field.
The documentation states:

Single-select custom field
Select a single value from a defined list of values. You can address them by value or id.

{{"customfield_11449" :
Unknown macro: { "value"}
}}
or
{{"customfield_11449" :
Unknown macro: { "id"}
}}

In that case I would use this format:

{
  "fields": {
    "customfield_12345": {
      "value": "My Value"
    }
  }
}

The issue with adressing the option by Value is if it is changed, the automation will then fail.
If the value is very unlikely to change, or you are managing the custom field and automation, this might be acceptable.

Another example would be a 'Text Field (single line)' field.

Text custom field

A single line of text.
"customfield_11450": "a single line of text"

{
  "fields": {
    "customfield_12345": "My Value"
  }
}

The suggestion from Kyle took me in the right direction but wasn't working for me.

In the end, had to remove the value field, so something like this:

{
  "fields":
{     "customfield_12345": "A value"
  }
}

This documentation helped to figure out that the value field was not needed: https://support.atlassian.com/cloud-automation/docs/advanced-field-editing-using-json/

PS: The suggestion from Yuri wasn't working at all - would get an error when trying to import the Json file.

{
"fields": {
"customfield_12345":

}
}

Does not work for my case. Says "field value must be a string". I submitted "2022-02-22" (the same value it was in REST representation of the issue)

This has affected us as well and after trying workarounds (exporting the automation to JSON, update the ID and importing) that didn't worked out, also using the official Atlassian documentation syntax with [customfieldname].ID didn't work, so I've tried to use the syntax issue.customfield_id to check the value of the custom field and Jira could validate the value even when there are two custom fields with the same type and name. 
Maybe this can help somebody out there fighting the automation. 

This is affecting us as well.  I have a business project with five fields (2 check box fields and 3 drop downs).  I've created the same fields in my software project - same name and types.  I expected the automation to be able to 1) understand the names are the same and copy the fields or 2) allow me to manually associate them.  An example for the second solution is Epic Name.  I can copy that from Summary.  i.e. the Business project summary = the software project's epic name.  Why can't I do that for all fields?

Juan you can use the suggestion from Yuri above regarding exporting the rule and updating the field to the ID.

Another option is to update using the 'Additional fields' section instead:

{
  "fields": {
    "customfield_12345": {
      "value": "A value"
    }
  }
}
 

I went with the second option and it works as expected.

In my case, automation doesn't recognize the project's custom fields at all - having a unique name doesn't solve the problem

This issue is having a significant impact on our organizations use of Automation - I believe the severity should be significantly higher than "minor".

Adding to what Kyle said above, even if this issue at it's core can't be fixed, I would expect that limiting the context of the item would suffice as long as the automation rule is also scoped to a specific set of projects

We also ran into this issue, and it was initially quite confusing because it occurred for a field that was previously working in automation rules, then suddenly was not.  It had a generic name like "Location", as I imagine that someone else in our institution created such a field in their company-managed project, which forced us to change the name of our field in our team-managed project.

It would be nice if this could receive a bump in priority.

I have this issue with using Jira Automation to copy Acceptance Criteria from a Service Project to a Team-Managed Project's Acceptance Criteria. It would be great if it copied just like descriptions.

Hey folks!
I found another way to workaround this without having to rename the custom field:

1. Export the rule to a JSON file
2. Open it and search for the section that shows something similar to this

   {
       "operations": [
           {
               "field": {
                   "type": "NAME",
                   "value": "Channel"
               },
               "fieldType": "com.atlassian.jira.plugin.system.customfieldtypes:select",
               "type": "SET",
               "value": {
                   "type": "NAME",
                   "value": "Portal"
               }
           }
       ],
       "advancedFields": null,
       "sendNotifications": true
   }
   

3. Then replace the "type": "NAME" with "type": "ID" and "value": "Channel" with "value": "customfield_xxxxx" where the xxxxx are the ID of your field
   • To find the ID of your field, you can follow the steps provided here
4. The result should be something similar to this:

   {
       "operations": [
           {
               "field": {
                   "type": "ID",
                   "value": "customfield_10223"
               },
               "fieldType": "com.atlassian.jira.plugin.system.customfieldtypes:select",
               "type": "SET",
               "value": {
                   "type": "NAME",
                   "value": "Portal"
               }
           }
       ],
       "advancedFields": null,
       "sendNotifications": true
   }
   

5. After replacing the references for the field, save the JSON file and import it as a new rule.

In my case I have he same field appearing in a classic project scheme and in a few next-gen projects.
So the automation recognizes this duality, but instead of simply operating on the next-gens, it fails.
Now I have to choose whether to give this automation up or to move the next-gens to classic. I won't rename the fields.
This is a rather absurd situation.

Considering Next Gen projects have been angled at being isolated so an individual team manages them rather then all the control being central like the legacy projects this is a stupid bug to exist.

This now means each of our teams can't re-use field names even if they don't have visibility to the other projects to workout if they're creating a duplicate...

https://getsupport.atlassian.com/browse/PCS-30733

https://codebarrel.atlassian.net/browse/AUT-2092