Jira Automation- Is this possible to do with automation?

[Don Hames]

If you edit an issue and change a field value on a custom field with an automation trigger listening for the field value changed, in the rule that processes this trigger, can you change a field value on a different issue?

Simply put, issue A field custom field change triggers a rule for field value changed, and in that rule, can you change a field value on issue B?

Thanks for your help. I'm stuck on this one.

[Bill Sheboy]

Hi @Don Hames 

I suspect the answer is: maybe.  What is the relationship between your Issue-A and Issue-B?

Specifically and once inside the rule, how are you determining Issue-B in your scenario?  If this can be determined from the trigger issue data, Issue-A, the answer is "yes".  You would just branch to that issue, such as with links, parent/child, or a JQL expression.

Kind regards,
Bill

[Don Hames]

@Bill Sheboy You are asking the same questions I had when I tried different ways to solve this. I am very hopeful that the last part of your answer is true. Let me try a better example of what I am trying to accomplish.

I have a project that contains Features, Epics, and Stories. The Epics and child Stories are templates. The Feature is a record that allows you to answer several questions that are used to determine which of the Epics you will need along with the child stories.

I have a manual trigger on the Feature, so when you complete selecting your answers, the manual trigger fires a rule let's call "Manual Trigger". In the Manual Trigger rule, conditions and actions determine which Epic and child Stories you need to perform your tasks.

I currently have separate rules for each possible combination of your answers. By changing the fields for your answers, when the Manual trigger is fired, it fires the appropriate rules that know which Epics and Stories you need to be created.

The Feature needs to be the parent of the Epics selected, and the Epics are the parent of the Stories associated with the Epics. This works great if you are going to Create an Issue. I had all the template text and field values inside the Create an issue action. I made the Epic a child of your Feature, and the Stories child issues to the Epics. 

To allow flexibility of the owner of this project to update any of the text in the template Epics and Stories, I switched from using Create an issue to Clone an issue. It seemed a simple change to remove the Create an issue to Clone the Epic needed and make it a child of your Feature. 

The problem I am having is the Clone issue only clones the current issue, i.e., the Feature. I have tried using a condition with JQL = the key of the Epic and then issuing the Clone an issue. Nothing works.

My conclusion is Clone an issue only works on the issue that fired the rule that is doing the cloning. So if my Manual Trigger rule can change a value in the selected Epic, that would fire a rule that would make the Clone an issue. But I do not know how to update an Epic from the Manual Trigger rule running on the Feature.

I am open to any suggestions. I am willing to try any scenario that seems feasible. If this explanation is unclear, please let me know, and I will try again with the explanation. 

[Bill Sheboy]

The clone action operates on the current {{issue}} at a certain point in a rule; context is important thing.  For example with this rule:

• trigger: manual.  At this point, {{triggerIssue}} and {{issue}} refer to the same issue.
• action: an action.  At this point, {{triggerIssue}} and {{issue}} refer to the same issue.
• branch: to one or more issues.  At this point, {{triggerIssue}} and {{issue}} refer to the same issue.
  • action: another action, such as Clone At this point, {{triggerIssue}} refers to the trigger issue and {{issue}} refers to the current branched-to issue.
• action: yet another action.  Once again, {{triggerIssue}} and {{issue}} refer to the same issue.

Thus if you branch to the issue you wish to Clone, that will be the source for the cloned fields.

If that does not help, please consider posting images of your rules and and the audit log details showing rule execution.  That may provide context for what you are observing.

[Don Hames]

@Bill Sheboy, I'm visual, so maybe I can better explain this with a graphic.

The Tracking Project contains all the Epic and Story templates needed to create a Tracking Feature for a user. The user creates a new Tracking issue in the Tracking Project. On the Tracking issue, there are several choices that the user makes their selections from Select List (single choice) custom fields.

Users execute the manual trigger on the Tracking Project Feature issue when their selections are complete. The Manual Trigger automation rule executes, and based on the user's selections, it clones the appropriate Epics and Stories in the Tracking Project.

The user will use these to complete the Stories, which can be followed in the Tracking Project.

Problem: 

Since the Manual Trigger rule was associated with the Tracking Project Feature, cloning the Epic and Story templates fails as it clones the Tracking Feature, not the Epics or Stories. I have used several methods to select the Epics and Stories, but they all result in cloning the Feature. The {{triggerIssue}} and the {{issue}} refer to the Tracking Feature.

Questions:

How can you select a different issue, i.e., the Epics and Stories, in the same project and clone it correctly? I have tried every issue condition type with the JQL selection of key = Epic-101, and none of them result in the successful cloning of the Epic. All attempts result in cloning the Tracking Feature.

Here is the issue condition trying to select Epic called MRM-441.

Here is the overall flow of what the automation needs to do:

[Bill Sheboy]

Yes, I understood that, and so I suggested branching.  Assuming your "templates" are example issues, let's try below.  If instead you are using some addon app for "templates", please look at the documentation for that addon to learn what automation capabilities are supported.

In your rule, in the Tracking Project, you have your manually triggered rule.

Someone triggers that rule from a Feature.

So in this first rule you could have...

• trigger: manual
• condition: issueType is Feature (just as a precaution)
• branch: on JQL to select your template issue for an epic
  • action: Clone (this will attempt to clone the epic referenced in the JQL), setting the parent to the trigger issue's key
  • ...as needed, repeat to add any other epics based on your fields

I am not using the Premium version, so if setting the parent doesn't work inside the branch, you would need to do this instead...

• trigger: manual
• condition: issueType is Feature (just as a precaution)
• branch: on JQL to select your template issue for an epic
  • action: Clone (this will attempt to clone the epic referenced in the JQL)
• branch: on created issue (this will walk the epics created)
  • action: edit issue using JSON to set the parent to the trigger issue

Please note above I indicated first rule, as I suspect your use case will be too complex to complete within one rule.  Instead create a second rule, triggered on the creation of an epic, and to add its child stories by cloning from the template issue.  This second rule would be triggered based on the actions of the first one, so enable the "Allow Rule Trigger" in the second rule's detail settings.

• trigger: issue created
• action: re-fetch (this slows down the rule by reloading the data before proceeding)
• condition: issueType is Epic (just as a precaution)
• branch: on JQL to select your template issue for a story
  • action: Clone (this will attempt to clone the story referenced in the JQL), setting the Epic Link (or parent) to the trigger issue

[Don Hames]

I followed your suggestion:

• trigger: manual
• condition: issueType is Feature (just as a precaution)
• branch: on JQL to select your template issue for an epic
  • action: Clone (this will attempt to clone the epic referenced in the JQL), setting the parent to the trigger issue's key
  • ...as needed, repeat to add any other epics based on your fields

The cloned record was a clone of the Feature. Here is the branch to select Epic, but it did not work.

[Bill Sheboy]

I just tried this and it worked as I described, where the cloned issue is from the branched-to issue...not the trigger issue.

Please post images of the audit log showing the details of execution when the rule does not work as you expect, and of the details of your Clone action.

[Don Hames]

Bill, would you mind posting some screenshots to show how you did this differently than my example above? If I am missing anything, maybe the visual will help. Thanks.

[Bill Sheboy]

Here is my test rule for cloning from the branch.  For this example, I used only user stories.

In my test rule, I have two clones: one after the trigger to test cloning the trigger issue correctly and another inside of the branch, testing that the branched-to issue is cloned correctly.

I cannot see your entire rule, only what you showed.  So I cannot confirm how similar your rule is to this one.  For example, what is the purpose of the edit on the apparent field "Manual Trigger", and what is the actual rule trigger?