The solution provided here can, of course, be expanded and customized with different designs. The key is to understand and convey the underlying logic. First, a request form is designed on the Customer Portal as follows:
Next, if the user selected as the "Coverer" meets the necessary criteria while the issue is in the approval status, they are added to the "Approvers" field using a rule like the one below:
lookupIssues:
"Request Type" = "Out of office request (IT)" AND statusCategory != Done AND "Start date[Date]" <= startOfDay() AND duedate >= now() AND reporter ="{{issue.customfield_10003}}"
P.S: In this case, {{issue.customfield_10003}} is User field - Actually, the real name of this field is User, but I've listed it as Coverer Approver on the portal side. It needs to be the same field as the User in {{lookupIssues.User}}, which is the last step in the automation process.
Hi @Muhammet Ayal
Nice solution.
Still I would move the conditions from the trigger ot the rule, as this has proved to cause timing issues.
For those provisioning their users from an idp, and are provisioning the Manager attribute, it is possible to use .manager in smart values referencing user fields.It only returns the UUID of the manager and doesn't go any deeper than that, but for editing fields through automation that is good enough.
It could be something along the lines of:
Trigger:Scheduled - Every X days
IF Status = Manager ApprovalIF status changed Y days ago*
Edit work item - Approver --> {{approver.manager}}**
*The {{Request Type.currentStatus.statusDate.jira}} value used in this example is only available for JSM it seems.**In our site Approvers = customfield_11700
@Marc -Devoteam- Hello,
This process varies depending on the approval design and can, of course, become more complex.
But as the name suggests, this is a "workaround solution". Hopefully, Atlassian will include this as a default in the product.
In your case, manager escalation is working. But in the situation I'm describing, a user manually selects the backup approver for their desired date range.
Hi, I have a quick question. I tried this approach, and it works perfectly with my team. However, what happens if a request requires multiple approvers? It seems like the automation overrides everything and replaces all the existing names in the field. Do you have any ideas on how to handle that?
Hi Phương,
You have found the main risk with this Automation approach. If the rule replaces the Approvers field, it can remove people who were already meant to approve the request.
If you continue with Automation, make the field update additive and test it on a request containing several existing approvers. The result should contain the original list plus the coverer—not a new replacement list.
Disclosure: I build Approval Nudge for JSM.
Its planned-absence feature takes the safer approach: it adds the stand-in as an additional approver for the selected dates. The original approver stays on the request and can still respond. The app also records what it changed in an internal comment.
One limitation is important: this works with approval steps using the Approvers field. Group-backed approval steps cannot safely accept an added individual approver.
Marketplace page:https://marketplace.atlassian.com/apps/971596656/approval-nudge-reminders-escalation-for-jsm-approvals
I hope that helps clarify the difference between adding cover and replacing the existing approval list.
It looks like you're new here. Sign in or register to get started.
