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?

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.