Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Email notification to issue creator (project A) after completion of a linked issue (project B)

Hi there,

The attached screenshot shows an automation rule for the following process:

  1. trigger manually in project A
  2. create new activity in project B
  3. link new task (project A-B)
  4. change status for task in project A
  5. send e-mail to team of project B
  6. monitor status of task in project B
  7. if status of task in project B equals "5 - done", send e-mail to creator of task in project A.

Unfortunately, the automation is successful only up to and including step 5. The status labels are different in both projects.

I am looking forward to your tips and ideas.

Many greetings,




1 answer

0 votes
Tessa Tuteleers Community Leader Jan 04, 2023

Hi @Christopher Dick , 

Welcome to the community! 

If I understand correctly, you want to keep track of the status of the newly created task and act when it is done. 

However, the trigger of this particular rule was the manual action. It can do stuff and act on conditions as they are right now, but then the rule will simply stop. 

If you want to act when an issue closes, this is a different trigger you need to monitor, so you will need to create a new rule for this. 

Hope this helps

- Tessa

Hi @Tessa Tuteleers,

Thanks for the quick feedback.

Then why is there a "Rule-Branching / Related Operations" if I can't monitor the statuses of the linked operation?

If I really need a separate second trigger in project B, then it gets complicated to uniquely identify the original task in project to send a message to the user who fired the manual trigger. I don't even want to think about special cases where the manual trigger is fired multiple times.

- Christopher

Tessa Tuteleers Community Leader Jan 04, 2023

Hi Christopher, 

the branching is there to be able to find different issues related in any way (other issues in epics, sibling subtasks, issues with the same duedate,...) and update them. 

There are a few ways to identify the "a-issue":

  • (assumption) if the creator is assignee of the a-issue
    • add the key as metadata on the b-issue when you create it in a hidden field or label
    • use a special link type to create the b-issue so you can find your way back
  • add the creator of the b-issue in a custom field on the b-issue -> because this creator might not be assignee of the a-issue anymore, so how would you know who it was?

That's just the way rules work, they have a trigger and when it is triggered, the stop. The don't keep monitoring other stuff. You would have a lot of rules that just keep running and listening and never stop, it wouldn't be manageable. 

- Tessa

Hi Tessa,

Thank you for the explanation.

Unfortunately, it could happen that the user who fires the manual trigger is not himself the assigned person or the author of the issue (A).

Moreover, the triggering user has no permissions on issue B and is not a member of project B.

It would probably be best to store the email address of the triggering user in a new field in issue B.

Unfortunately, I've only been working in my new team role for a few days and don't know the configuration options of Automation/Smart Values that well yet.

How can I pass the email from the triggering user into a custom field in task within a rule? So far I have not been able to do this although the names and types for the fields were identical in a previous test.

Many greetings,

Tessa Tuteleers Community Leader Jan 04, 2023

Hi @Christopher Dick , 

no worries, that's why were here :) 

You can create a user field for this (e.g Creator) for project B

You can add the user to that field in the b-issue, even if he has no permissions to see that issue. 

In your second rule, you can then send an email to that user based on the field. 

Setting the user that initiated the rule is a little tricky. 

First, you need to find the custom field id, and then set the initiator in the additional fields option as shown in the screenshot below (replace the highlighted number with the id of your custom field). 

You can find the ID by going to you custom field configuration, it's in the url

Screenshot 2023-01-04 at 14.58.37.png

Good luck! 

- Tessa

Hi Tessa,

unfortunately an error occurred:

  • "Create operation
    Error while creating the operation
    data was not an array (customfield_11520)"

Additional fields in Automation rule:

  • {
         "fields": {
         "customfield_11520": {"id":"{{initiator.accountID}}" }


Screenshot (Custom Field)

2023-01-04 15_33_33-Testmanagement (_) - Vorgangstypen - JIRA.png

Tessa Tuteleers Community Leader Jan 04, 2023

@Christopher Dick , 

this is a multi-userpicker then? The "array" tells you that a list of multiple values are expected, even if there is just 1. 


"fields": {
"customfield_10003": [{"id": "{{initiator.accountID}}" }]


- Tessa

Thanks has worked :)

However, I still have two individual date fields in operation A, which I want to copy to operation B.

Do you have a sample for the syntax?

Many greetings,

Tessa Tuteleers Community Leader Jan 04, 2023

Glad you got it working!

Datefields normally can be copied natively, by using the "choose field to set", and then copy and choose the origin field. 

Screenshot 2023-01-04 at 16.31.06.png

Kindly mark the answer as accepted so other users can find the solution if they need it. :) 

- Tessa

Unfortunately, the following did not work:

  • {
    "fields": {
    "customfield_11520": [{"id": "{{initiator.accountID}}" }],
    "customfield_11100": [{"id": 11100 }],
    "customfield_11498": [{"id": 11498 }]

The following error message:

  • Unknown fields set during creation. These may not be available for the project/type. Check your configuration for custom fields. Fields ignored -
    Start date (customfield_11100), End date (customfield_11498).

The fields are definitely present in both projects like this:

  • 2023-01-04 16_36_56-Vorgangsnavigator - JIRA.png

Many greetings,

Unfortunately, an error message occurs when copying:

  • Multiple fields found with the same name and type: .
    Start date (com.atlassian.jira.plugin.system.customfieldtypes:datepicker), End date (com.atlassian.jira.plugin.system.customfieldtypes:datepicker)



2023-01-04 16_49_15-Automatisierung - JIRA.png

Hi Tessa,

I could already save the creator of issue A in issue B.

Unfortunately, in a new trigger in project B, I could not inform the creator of issue A by email after the completion of issue B.

I tried the following values as the recipient of the email without success: {{customfield_11520}}, {{issue.customfield_11520}}, {{issue.customfield_11520.value}}


Error message:
Send email
The email could not be sent because the "To" field is empty. If you referenced a field, it may be empty.



2023-01-05 09_18_28-Automatisierung - JIRA.png


Many Greetings,


Suggest an answer

Log in or Sign up to answer

Atlassian Community Events