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

Even limiting the context of the field to a project does not fix the issue.