Hi there,
The attached screenshot shows an automation rule for the following process:
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,
Christopher
Screenshot
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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":
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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,
Chris
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
Good luck!
- Tessa
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Tessa,
unfortunately an error occurred:
Additional fields in Automation rule:
Screenshot (Custom Field)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
this is a multi-userpicker then? The "array" tells you that a list of multiple values are expected, even if there is just 1.
Use:
{
"fields": {
"customfield_10003": [{"id": "{{initiator.accountID}}" }]
}
}
- Tessa
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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,
Chris
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
Kindly mark the answer as accepted so other users can find the solution if they need it. :)
- Tessa
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Unfortunately, the following did not work:
The following error message:
The fields are definitely present in both projects like this:
Many greetings,
Chris
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Unfortunately, an error message occurs when copying:
Screenshot:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
Screenshot:
Many Greetings,
Chris
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.