Flexibility with amount of approvers

Hi @Brian Jennings 

There is no proper solution for this, but changing the approval setting in the related workflow.

I would not take the road to add fields and automation in my opinion this would add complexity rather then simplify  the process.

The cleanest and simples way is to change the approval step.

If there are frequent changes based on the approvers, I would look at the why there are so many changes, and is that audience then the right one to provide approvals?

I appreciate your knowledge & responses.

I spoke to my boss a little more concerning this matter. Another factor is that he would like that the approval group is associated with a service. His intent is that a "Service" field can be added to a change management ticket. Then, it would use the associated group to act as the CAB/steering committee. The bigger problem is that each CAB has a different amount of people in it, plus could change often. So, that adds more complexity. Because the approval setting is hard coded, it would be impossible to change that setting depending on which Service is selected. Meaning that the standard workflow approval approach will not work as he would like it to.

Correct me if I'm wrong, but at this point, the only safe answer is to have separate workflows for each approval group tied to their own issue types. This is the best bet until Atlassian enhances how approvals work.

Hi @Brian Jennings

The dropdown in your screenshot offers a specific number, a specific number per group, or everyone. None of those is a proportion. The setting underneath takes one though. That control writes a workflow property whose mode can be a percentage, so put it on 51 and the step works the number out from whoever is in the approver field. 8 approvers wants 5, 12 wants 7, and the config stops needing you.

The UI won't hand you 51. Everyone is percentage mode pinned at 100 and that is the only percentage it offers. For any other value you read the workflow with POST /rest/api/3/workflows, change conditionType to percent and conditionValue to 51 on that status, then POST the whole thing back to /rest/api/3/workflows/update. Partial bodies get a 400, so send every status and transition along with the current version number.

I ran it on a test site before writing this, with a user picker holding the approvers. Two approvers at 40% cleared on one approval, ceil(0.8) being 1. The same two at 51% didn't, ceil(1.02) being 2. One approver at 51% cleared.

Now the price. Atlassian's KB on these properties says setting them by hand is not recommended and may lead to workflow issues, and the workflow validator answers APPROVAL_MISCONFIGURED for any percentage but 100, so you own this one. The decrease half of your question also has teeth, because a proportional threshold recomputes when the list changes. I pulled one of two approvers off a request sitting on a single approval and it went straight through to Waiting for support. On your numbers, taking four people out of a group of 12 can approve something that was still waiting.

On the counting custom field, the step can't read one. conditionValue is a literal and nothing in that config lets the count come from a field. The supported way to stop the hand-editing is the middle option in your dropdown, which holds at say 2 per group however big the group gets, assuming Managers is a group picker. I only ran the percentage against a user picker though, and Atlassian's own property table pairs percent with everyone and the per-group option with a multi-group picker, so if Managers holds groups rather than people, try it on a test project first.

Company-managed. Team-managed approvals sit on the request type and I haven't tried this there.

Hello @Brian Jennings 

Theres even ancient JAC Ticket related to that [JSDCLOUD-4223] Consider declined only when several approvers have declined - Create and track feature requests for Atlassian products.

I don´t see here clean solution besides slight design change for approval settings.

Approvals are one of those areas where you ideally want a fairly stable group of approvers with as little fluctuation as possible. Otherwise, highly customized approval processes can break quite easily when people, roles, or responsibilities change.