I have a form in JSM (cloud) with all of the fields linked to Jira fields. I have an automation that creates a new work item, attaches the same form, and then copies the information over to the new form. (I actually have several of these processes running). On this one particular form, there are 2 fields (out of about 30) in which I get the error "We excluded the configured field from this action as it couldn't be found: , "I am using the Copy function in the Edit Work Item step. Specifically, Issue to Copy Value from: Trigger Work Item. with Field to Copy Value From: .All of the other fields are set to copy the same way, and they all work. It seems like the new work item (which is a different work item type) doesn't contain those 2 fields, but they were all created and added at the same time. The fields (all of them) are not set to be visible on the view screen. My first question is, in the error message, where could the configured field not be found? Source or destination? I've unlinked and relinked the Jira fields with the form. I've also surfaced the 2 fields on the view screen for the source and the information shows up there.Any thoughts on where to start?

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Unable to copy some fields in automation

Keith Jones

I have a form in JSM (cloud) with all of the fields linked to Jira fields. I have an automation that creates a new work item, attaches the same form, and then copies the information over to the new form. (I actually have several of these processes running).

On this one particular form, there are 2 fields (out of about 30) in which I get the error "We excluded the configured field from this action as it couldn't be found:

<Field 18>, <Field 25>"

I am using the Copy function in the Edit Work Item step. Specifically, Issue to Copy Value from: Trigger Work Item. with Field to Copy Value From: <Field 18>.

All of the other fields are set to copy the same way, and they all work. It seems like the new work item (which is a different work item type) doesn't contain those 2 fields, but they were all created and added at the same time. The fields (all of them) are not set to be visible on the view screen.

My first question is, in the error message, where could the configured field not be found? Source or destination?

I've unlinked and relinked the Jira fields with the form. I've also surfaced the 2 fields on the view screen for the source and the information shows up there.

Any thoughts on where to start?

Accepted answers

All comments

Mikael Sandberg

Automation is using the create/view screen to create new work items, so if the fields that you are copying over to the new work item is not on those screens that is why you get the error message, which is on the destination item. Think of it as a user creating the work item, if the fields are not on the screen the user cannot fill them out.

Keith Jones

Looking at the other fields, they are not associated with any screens - at least as shown in the Active Fields list, yet they copy over without any issue. In the listing below, the 3rd and 4th fields do not copy over. all of the others do, whether associated with a screen or not.

It's not just the destination that's causing problems. If I complete the form and then use automation to send an email with those fields, the 2 trouble fields are blank. I think I may just recreate those 2 fields and see what happens.

Christopher Yen

Hi @Keith Jones , do any other radio buttons copy successfully? and you're saying when using the smart value for those fields in an email no values are coming through?

Keith Jones

That was my first thought too - that it was related to the radio button field type, but I've got several others in this form that work just fine. And yes, if I generate an email and copy the values from the linked fields, those 2 fields are blank in the email.

Keith Jones

So I found out the "what", but not the "why". But that's okay - I've messed around with this long enough.

Turns out that there were 2 deleted fields by the same name (they were checkbox, not radio buttons). They were still in the temporary deletion period. For some reason, selecting that field in the smart value picker entered the custom field ID of the deleted items, not the current ones. Maybe because they were in the temporary deletion period? No idea, but I renamed the current fields and everything seems to work fine. <shrug>

Thanks for the help and feedback Mikael & Christopher.

Evelin Bayer - codefortynine

Hi @Keith Jones ,

Glad you figured it out - deleted fields with the same name confusing the Smart Value Picker is a nasty one to debug.

For what it's worth - if you're looking to avoid this class of problem altogether in the future: our Deep Clone for Jira app offers a Jira Automation action that clones a work item based on a pre-configured Preset. You don't reference individual Custom Field IDs in the automation editor at all - so there's no way for the Smart Value Picker to grab a stale or deleted field ID.

This is especially relevant when you're working with JSM Forms (formerly ProForma): Deep Clone copies the filled form including all field values as-is. No need to map 30 fields individually. Attachments embedded in forms also carry over cleanly - something that tends to be unreliable with native "Copy value from" actions.

Obviously not saying you need it for this specific case (you've already solved it!) - but with 30+ fields per automation, it might save you headaches down the road.

More details: Jira Automation documentation | Preset configuration options

Disclosure: I work at codefortynine, the vendor of Deep Clone for Jira.

Best,
Evelin Bayer | codefortynine

Olha Yevdokymova_SaaSJet

Hi @Keith Jones

That explains it — having deleted custom fields with identical names still in Jira’s temporary deletion period would definitely make this difficult to spot.

Since you mentioned you have several automations following the same pattern — create another work item → attach the same form → copy ~30 values — another approach you might consider is keeping more of that information in the form itself rather than maintaining a separate Jira custom field for every question.

Smart Forms for Jira, developed by my team at SaaSJet, works a little differently here. Form elements don’t all have to be backed by Jira custom fields. You can map only the values that Jira Automation, JQL, reporting, etc. actually need as Jira fields, while the rest of the structured information remains in the form.

It can also be useful when work items are cloned: Smart Forms are carried together with the work item. Submitted forms are copied as read-only submitted responses, while New/Draft forms create a fresh form instance on the cloned work item.

So for workflows with very large forms, you can potentially reduce something like:

30 form fields → 30 Jira custom fields → 30 copy mappings

to:

form response stays with the work item + only operational fields are mapped to Jira

Plus, all deleted form elements and its responses are stored withing form responses report, which can be exportable as exel or PDF or connected via API to external resourses.

That doesn’t change the cause of the issue you found — the stale custom field IDs were clearly the culprit here — but it can reduce how many custom field IDs the automation has to depend on in the first place.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-service-management-cloud

jira-service-management