I have a project in JSM Standard version. An issue type considers an approval process in the status AWAITING APPROVAL of its workflow. If the approver approves the item, the status must be changed to IMPLEMENTING, otherwise, if he rejects it, the status must be changed to REJECTED. For some specific reasons in my project, depending on the users choices while creating the item, the approver should receive an e-mail with links to "Approve" or "Reject" the item. To attend this restriction of my project, I need to create an automation to send an e-mail to specific approvers, depending on the choices made by the requester. So, this automation should be started when the status is changed from OPEN to AWAITING APPROVAL. Then it should check the conditions related to the choice made by the requester and, after that, it should be sending e-mails to the specific approvers, with links to approve or rejected the item. And, depending on the action by the approver, the item status should be changed, automatically and accordingly, to IMPLEMENTING or REJECTED. How can I get this automation running? Please, show me all details regarding it.
@Marcos Marinho can you share what you've tried so far? Are you running into any specific issues?
Hi, Mathew! Thank you in advance for your attention!
I have already created an automation with the info below, but it's not running as expected, because it does not makes the transition of the item from the status AWAITING APPROVAL to IMPLEMENTING or REJECTED. Basicaly, this automation just creates the e-mail with the links to aprove or reject, but it only redirects the approver to the item, when he/she clicks on the link.
Automation Structure:
1) WHEN an item is moved from OPEN to AWAITING APPROVAL
2) IF certain CONDITIONS are satisfied
3) SEND E-MAIL to specific approvers
Body of the message:
"
You have an item to approve or reject.
<a href="https://[mydomain].atlassian.net/browse/{{issue.key}}?workflowAction=approve">Approve</a>
<a href="https://[mydomain].atlassian.net/browse/{{issue.key}}?workflowAction=reject">Reject</a>
"
I need to know how to adjust the info in the body above, so that I can have the status transition (to implementing or rejected) occurring, as expected.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Instead of using automation to send the email, could you use the native JSM approval notice that comes with the Approve/Decline buttons natively? You could use your automation to add user to the approver field configured in your workflow when the appropriate conditions have been met.
Alternatively, we're having approvals send an email back into Jira adding a comment, and using Legacy Automation to trigger off that comment and transition appropriately.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Actually, it was my first implementation, but (maybe because the Standard version) I can't use the conditions I need on my project. Just to explain I little bit more, I have created on JSM an Access Control System. When the requester, for example, choose some IT System and profile in checkbox fields, depending on what was selected by user, some approvers should receive e-mail with these buttons. As I couldn't implement the approval using the native alternative, I had to try using automation.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Why were you unable to implement approval using the native functionality?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Because I didn't find in the native funcionality one way of configuring the conditions I need to implement. As per my researches, it could be associated with my JSM version (Standard), but I really am not sure about that. I don't have much knowledge to say that.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You're right, you can't set conditions on the approval email itself. And once the approver is added, the email will be sent.
You can use automation to ensure the conditions are met before setting the approver.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
That's what I'm trying to do. In the automation I have created, once the conditions are satisfied, an e-mail is sent to the chosen approvers, as expected. With the configuration below, in the body of the message, the links to approve or reject appear to the approver. The problem is: the transitions to the right status, when approved or rejected, are not occurring. And I do not know the parameters to make this happen.
"
You have an item to approve or reject.
<a href="https://[mydomain].atlassian.net/browse/{{issue.key}}?workflowAction=approve">Approve</a>
<a href="https://[mydomain].atlassian.net/browse/{{issue.key}}?workflowAction=reject">Reject</a>
"
As per my researches, may I would need the transition IDs related to the "Approve" and "Reject" links, in order to be possible the transitions, but I couldn't find these IDs.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
And I don't know what I would need to change in the parameters above, to include the transition IDs.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I don't know if you can use a web link to pass through workflow parameters.
What I'm saying is, set the conditions in the automation. Once the conditions are met, add the approver. Once the approver is set, the native approval email functionality should take over and send the email with the fully functional Approve/Reject buttons.
This allows you to use automation to define your conditions and use the native buttons without trying a workaround that may break if your workflow changes.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Now, I got your point, but I also tried this alternative. I mean, in the automation, after set the conditions, I stabilished a step of editing the item, where I defined the aprovers. The problem was: in the item, I have (in portuguese version) a field called "Aprovadores", but I couldn't fill it with the name of approvers automatically, using the automation. The native funcionality requires that the Agent manually sets the approvers. As per my researches, it's because this field is restricted to JSM. So, I tried to insert another field in my project called "Approvers", which is considered (I guess) a JSM custom field. And, this way, I could insert the approvers using the automation, but in this scenario, unfortunately, the e-mail was not sent to the approvers set. I do not know why.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
It seems the native functionality forces the use of the field "Approvadores", because if I set the approver manualy, the e-mail is sent as expected. But I need it running automatically.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
The native functionality email is triggered off the approver field defined in your workflow. If you set that as 'Approvers' instead of 'Aprovadores', it sounds like this should work as you desire.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I had also tried this option, but notice in the screen below that I get an error message, saying that this field already exists and that I have to try another one. Also notice that the Save button ("Salvar") is not available to click, when I set the field to "Approvers".
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Is it possible you're using the same field in a different place in the workflow?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I guess you are right, but I'm using it in other issue types of my project. Not in this one I'm testing. Should I try to rename these fields in the other issue types of my project?
Again Mathew, thank you very much for your excellent support on that! I really appreciate it!
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.