How to retain access to approvals for multi-stage approvals

Question

We have a few workflows where more than one status requires approval and the "Approvers" field is used more than once for each status.

For example, our issues may have ComplianceApproval, ManagerApproval, and ServiceOwnerApproval. Each of these statuses has different approvers based on the reporter.

For example; Say we have a ticket that requires both ManagerApproval and ServiceOwnerApproval and the workflow goes something like this:

* The ticket is set to the status "Waiting Manager Approval" and the "Approver" field is set to the reporter's manager.

* The manager approves the ticket.

* The ticket is then moved to "Waiting Service Owner Approval" and the Approver field is changed to the Service Owner.

* The service owner then approves, and the ticket is moved to in progress.

For the issue in this example, the manager wants to go back and review the ticket they approved, since they've been removed from the "Approvers" field they get a "No access" message when attempting to open the ticket in our customer portal.

My question is, is there a best practice method that anyone out there are using to be able to have previous approvers retain access to tickets?

TLDR - I need a way to allow approvers to retain access to a ticket they've previously approved without spamming them with notifications by adding them to the "additional participants " field.

Additionally, I've thought of the following options;

* Add approvers (who have approved) to the "Additional Participants" field
* Create multiple fields to be used for each approval status. For example, "ComplianceApprovers" "ServiceOwnerApprovers" "ManagerApprovers"

In option #1, this would mean approvers are spammed with notifications on the ticket after they've already approved it.

In option #2, I'm unsure if my "custom approval fields" would allow users access to the ticket, or if Jira only permits users in the default "Approvers" field access to the ticket.

I feel like there is no great way to handle this situation. Does anyone else out there have something clever they've come up with?

Mikael Sandberg · Answer

As a request participants you can decide if you want to get notified or not, there is an option in the email that is sent out to turn it off. If you want all your approvers to have access to it after the request has passed the status that they are the approver of they have to be added as request participants. If you add then all at the same time or only when the request get to that step is up to you.

Your other option would be to turn off the customer notifications for updates and use an automation instead to let the reporter know that the request has been updated, but that would affect all your request types within that project.

Jeret Shuck_hfty3t · Answer

Hey Mikael, thanks for the response.

That's more or less the direction I'm going. However, in my use case, I sometimes have 10 or more users as approvers for a given status. If I were to add all 10 users as participants, they'll be flooded with ticket notifications throughout the ticket's lifespan; which is not what I want.

That said, I'm currently dabbling with the smart value "{{issue.customfield_10205.first.approvers.approver.accountId}}" which is the "Approver" field within our instance.

TLDR - Whoever clicks the "Approve/Deny" button, will get added as a participant. Again, I'd prefer to be able to give them access to the ticket, without signing them up for all the notifications that come with being a member of the "Request Participants" field.

Mikael Sandberg · Answer

In order for approvers to have access to the request after they approved it you have to add them as request participants, since that is the field that controls who have access to the request besides the reporter.

I have a employee change request that have 4 different approval steps, and I use multiple user picker fields for this, mainly so it is easy to find who the approvers are when we do audits instead of having to look at the history. All approvers are also added as request participants so they have access to the request anytime.