Custom fields in Work Management

[Angie Adams]

We have a couple of teams moving their teams work into work management projects. (company managed projects) These projects have custom fields and custom issue types.  They share an issue scheme with the same fields in both projects.  We've run into a couple of issues related to the custom fields.

1. The custom fields are not found when used in an automation.  When cloning the issue into another project, the custom fields are not updated on the created issue.
2. The forms would be beneficial for the team members and others for providing issue information in a user friendly way - especially for non-jira users.  Unfortunately, none of the custom fields are available to add to the form in the form designer.

Hoping someone has ideas on how to troubleshoot & resolve this. 

[John Funk]

Hi Angie,

If you have created custom fields that have a Context associated with the original project, you will need to add the new JWM project also to the Context. And make sure the fields are on the Create screen used by the JWM project. 

[Angie Adams]

@John Funk thanks for your response.  I'm a project admin but not an admin for our Jira instance so I'm not familiar with setting set context.  Is that an additional step to adding them to the project?  I ask because the fields are visible in all of the projects and want to provide the right guidance to our Jira admin.

[John Funk]

If you see the fields in the JWM project then it’s not a Context problem.  When you click the Create button and put in the JWM project, do you see the fields in that screen?

[Angie Adams]

@John Funk yes, they are visible in all of the projects using that issue scheme.

[John Funk]

Ah, okay. Try adding a Re-fetch issue action after the initial trigger. Or try the new Delay action! For maybe 3 or 4 seconds. Update and then test it again. 

[Angie Adams]

Like this? (that produced same result)  the issue is that when the issue is created the copy field from current issue is returning the error of field not found - while the fields are in both projects which share the same issue scheme and fields.  it gives the same error when creating the new issue within the same project.

[John Funk]

Can you create a new issue from scratch using the Create button in the target project with all of the same values that would get copied over? 

[Angie Adams]

Manually, yes I can create an issue in both projects with the same fields and values.

[Trudy Claspill]

Hello @Angie Adams 

Regarding #1: When asking for help with an automation rule it will help us help you if you provide screen images that show the complete rule and details of each step as well as the output in the Audit Log for an execution of the rule that demonstrates the problems.

Regarding #2: What are the custom field types of the fields you want to add to the forms? Are they among the custom field types listed here?

[Angie Adams]

@Trudy Claspill  Thanks for the quick reply and recommendation.  Also, while i would normally break these 2 out into separate questions, the failing fields / missing fields appear to be largely, though not exactly, the same for both #1 and #2.

Regarding #1: here is a screen shot of the rule and resultant audit logs. The different projects share the same issue scheme & fields. I've validated the custom field ID (example screen shot of one field that failed). 

Regarding #2: yes. It doesn't appear to be based on field data type. here are the fields that are available in the form.  I've included 2 screen shots below.  the first one is the fields available via the form config.  the 2nd being the custom fields that are not available.  they include: URL, text single line, text multi-line, date picker, numeric.  a field of each of those types are in both screen shots. 

[Trudy Claspill]

Hello @Angie Adams 

Regarding the Automation Rule:

Do I understand correctly that users are manually triggering this rule from their own projects to create a new Task in a JWM project which is Company Managed? You said the projects share schemes, but just to confirm - are the projects from which they trigger the rule also Company Managed? And are those source projects Software, Service, or JWM?

In the Automation log I see that it lists 6 fields as "unknown" but it is unclear from the image of the Create Issue action if all these fields are present in that action and being set. Can you confirm that all 6 of the fields mentioned in the message are among the fields you are trying to set in the Create Issue action?

The log also mentions the StartDate field, but I don't see that field in the images you provided for the Create Issue action.

I see that you have used a mix of references. I don't know that these are causing any of the problems but I recommend the following corrections.

- In each field where you have "Copy .. from Current Issue" I recommend that you change that to "Copy ... from Trigger Issue"

- In the Description field if your use of issue. is intended to refer to the information in the issue from which the rule was triggered, then use triggerIssue. instead.

- In the Description field you have a few syntax errors:

-- triggerIssue. is case sensitive. Make sure the "I" in "Issue" is capitalized.

-- For Project Type you have only one opening curly brace. It needs to be two curly braces.

Additionally, you are trying to set the Parent of the newly created issue to be the issue from which the rule was triggered. You are creating a Task, so typically the only issue type that could be its parent is an Epic. Is the rule intended to be triggered only from Epic issues? If so, I recommend that you add a Condition after the Trigger to confirm that the issue type of the trigger issue is indeed an Epic.

[Angie Adams]

@Trudy Claspill  Thank you for the tips.  my responses are below.  I should have qualified that those configurations are attempting to work around the Copy <field> from current issue.  The options are "Set" & "Copy".  The Copy returns an error (see the screen shot below for Target Go-Live Date from Current Issue

Regarding the Automation Rule:

Both projects are JWM and company managed. 

all 6 of the fields mentioned in the message are among the fields i am trying to copy in the Create Issue action.

The startDate field is in the create issue action, just not in the screen shot.  

In each field where you have "Copy .. from Current Issue" I recommend that you change that to "Copy ... from Trigger Issue"

Thank you.  This was an artifact of me

- In the Description field if your use of issue. is intended to refer to the information in the issue from which the rule was triggered, then use triggerIssue. instead.

- In the Description field you have a few syntax errors:

-- triggerIssue. is case sensitive. Make sure the "I" in "Issue" is capitalized.

Ah, thank you.  

-- For Project Type you have only one opening curly brace. It needs to be two curly braces.

 Ah, thank you.  

Additionally, you are trying to set the Parent of the newly created issue to be the issue from which the rule was triggered. You are creating a Task, so typically the only issue type that could be its parent is an Epic. Is the rule intended to be triggered only from Epic issues? If so, I recommend that you add a Condition after the Trigger to confirm that the issue type of the trigger issue is indeed an Epic.

Yes it is.  added condition

__________________

Below are the updates to the workflow & the audit log.  I modified the automation to create a task from an epic in the same project and copied the fields.  The errors persist.  (thank you for your assistance!)

[Angie Adams]

@Trudy Claspill  Thank you for the tips.  my responses are below.  I should have qualified that those configurations are attempting to work around the Copy <field> from current issue.  The options are "Set" & "Copy".  The Copy returns an error (see the screen shot below for Target Go-Live Date from Current Issue

Regarding the Automation Rule:

Both projects are JWM and company managed. 

all 6 of the fields mentioned in the message are among the fields i am trying to copy in the Create Issue action.

The startDate field is in the create issue action, just not in the screen shot.  

In each field where you have "Copy .. from Current Issue" I recommend that you change that to "Copy ... from Trigger Issue"

Thank you.  This was an artifact of me

- In the Description field if your use of issue. is intended to refer to the information in the issue from which the rule was triggered, then use triggerIssue. instead.

- In the Description field you have a few syntax errors:

-- triggerIssue. is case sensitive. Make sure the "I" in "Issue" is capitalized.

Ah, thank you.  

-- For Project Type you have only one opening curly brace. It needs to be two curly braces.

 Ah, thank you.  

Additionally, you are trying to set the Parent of the newly created issue to be the issue from which the rule was triggered. You are creating a Task, so typically the only issue type that could be its parent is an Epic. Is the rule intended to be triggered only from Epic issues? If so, I recommend that you add a Condition after the Trigger to confirm that the issue type of the trigger issue is indeed an Epic.

Yes it is.  i will add.

__________________

Below are the updates to the workflow & the audit log.  I modified the automation to create a task from an epic in the same project and copied the fields.  The errors persist.  (thank you for your assistance!)

These are the fields for the issue type in the project.  (it looks like StartDate was changed to a different Start date field, so i'll make that update as well)

[Trudy Claspill]

In the latest screen image of your Create Issue action I don't see any of the changes I recommended to the "Copy ... from" or the use of issue vs. triggerIssue in the Description.

I would recommend that you at least change the "Copy ... from" to reference Trigger Issue instead of Current Issue. At that point in the automation, it may be getting confused by what issue you are referencing when you say "Current Issue" there. I don't know that for a fact, but for clarity if you want to copy from the Trigger issue then you should specify Trigger Issue there.

When you pull down Change fields to set and search for any of these problematic fields, do you find it returning more than one field with the same name? Jira allows multiple fields with the same name, which can also cause ambiguity in Automation Rules.

[Angie Adams]

@Trudy Claspill Thanks. 

In the latest screen image of your Create Issue action I don't see any of the changes I recommended to the "Copy ... from" or the use of issue vs. triggerIssue in the Description.

I would recommend that you at least change the "Copy ... from" to reference Trigger Issue instead of Current Issue. At that point in the automation, it may be getting confused by what issue you are referencing when you say "Current Issue" there. I don't know that for a fact, but for clarity if you want to copy from the Trigger issue then you should specify Trigger Issue there.

When using COPY, rather than SET, the only place where that is an option is for the Parent field which was changed.  All other fields I can Set or Copy.  I selected Copy.  with that option, there is nothing additional to configure.  

When you pull down Change fields to set and search for any of these problematic fields, do you find it returning more than one field with the same name? Jira allows multiple fields with the same name, which can also cause ambiguity in Automation Rules.

I used Copy rather than Set.  There was a duplicate (StartDate vs. Start date for example), but none of the other fields have another field with the same name in the field selection list. (example below)

For thoroughness, I updated the workflow for 1 field that is erroring using Set & triggerIssue.  It still failed.  I've included screen shots showing the custom field ID, that it's the only field with that name, & the configuration using triggerIssue as well as the resulting error.

[Trudy Claspill]

When using COPY, rather than SET, the only place where that is an option is for the Parent field which was changed.  All other fields I can Set or Copy.  I selected Copy.  with that option, there is nothing additional to configure.  

After selecting COPY the text "Copy ... from Current Issue" displays. Click your mouse directly on that text and a pop up will display that allows you to select the source issue (and source field).

Has there been a lot of editing of this rule, or was this rule copied from another rule? Sometimes things go wonky in those cases. You might want to try recreating the rule from scratch.

One other debugging option I can think of is to output all the data for a Task issue to confirm the custom field ids for the fields within the issue. Refer to "Finding your smart value"

https://support.atlassian.com/cloud-automation/docs/find-the-smart-value-for-a-field/

The output should include both the visible field names and the underlying customfield_##### identifiers.

[Angie Adams]

@Trudy Claspill Thank you! I admit I feel a bit foolish.  Thank you so much for sticking with me to help figure this out.  

[Trudy Claspill]

I notice you marked your question as solved, clicking Accept Answer for my answer.

Is the problem solved? Was it changing the Copy From options that solved it?

We are all here to learn and help each other. There is so much to know about Jira it is hard to know everything and features change regularly. Even Community Leaders routinely get help from others.

[Angie Adams]

@Trudy Claspill  - I jumped the gun on accepting - I was so excited to see something I had not looked at.  It did not solve the issue unfortunately.  I'm new to automation with most of it in product discovery, which is just different since nearly all of it is custom fields.  Any other suggestions? I'm thoroughly stumped.

[Trudy Claspill]

Have you tried the last two debugging options I suggested?

Has there been a lot of editing of this rule, or was this rule copied from another rule? Sometimes things go wonky in those cases. You might want to try recreating the rule from scratch.

One other debugging option I can think of is to output all the data for a Task issue to confirm the custom field ids for the fields within the issue. Refer to "Finding your smart value"

https://support.atlassian.com/cloud-automation/docs/find-the-smart-value-for-a-field/

The output should include both the visible field names and the underlying customfield_##### identifiers.

A third option that might be worth trying is seeing if you can change those fields through an Edit action rather than as part of the Create Issue action. In that case you would need to use a branch (For Each / Related Issues / Most Recently Created Issue) to change the focus of the rule to the newly created issue and put the Edit action within the branch. 

[Angie Adams]

@Trudy Claspill thanks for the additional suggestions. I did copy it over in order to streamline it from the initial rule for troubleshooting. There were a lot more actions in the original automation that weren't necessary for troubleshooting the create issue.  I will try what you suggest & report back.