Patricia Schooling - Hi
I had a look at your workflow - are Reviewer and Approver people or group columns which allow multiple selection?
Struggling to understand what you mean by "all the identified approvers "?
Yes, "all must agree" might be the option you need.
But it depends on how you want to build the process. What happens if 2 say thay need changes but two others say it's ok.
If you want everyone to accept without changes then "all must agree" is the option of choice.
The problem that I understand is that if one person chooses to need changes all other pending tasks will be set to not required. I think you want to first wait for all responses and finally send them to the initiator. Is that right?
If you want to try to achieve this you can't use flexi task because it will always set pending tasks to not required once it sees that the outcome behaviour can't be or has already been fulfilled.
So in that case you would have to create individual tasks for everyone and wait for all tasks to complete before moving ahead.
How many people do you have in such an approval process?
Thanks for posting!
The approvers are identified in a document library column. The document creator completes this column with the people needed to review and approve the document. There is no limit to the number of people that can be added as approvers but, on average, I foresee around 3-4 per document.
The requirements for the system are:
- the ability to identify different people as approvers for each document;
- the review and approval process in one workflow, with the review stage automatically moving to "approve" if all approvers select this outcome;
- the ability to gain an outcome from each approver. If an approver requests changes and another approver selects "approve", the workflow goes back to the start of the review cycle and the document remains "pending" until changes identified are implemented. The review cycle then starts again once the document is flagged as "ready for approval" and the document is checked in.
Individual tasks sounds like an option for a way forward, but can this be achieved if the number of approvers may change from document to document?
Yes individual tasks is an option here:
based on what you have said below you don't mind if some approvers don't respond if one has asked for changes which is what will happen with the behaviour discusses.
Hi Cassy! I have set individual tasks in the flexi-task but it doesn't achieve what I want it to. I still want all approvers to respond. I'll try to explain the expected cycle as best I can:
1. Initiator uploads a document and fills in all mandatory columns, including "approvers". They enter two names, Tricia and Cassy.
2. The workflow starts as described previously.
3. Tricia completes the task, responding "approve"
4. Cassy completes the task, responding "changes required". The document automatically checks out and the "ready for approval" status changes to "no, not yet".
5. Offline, changes are discussed and implemented (or not).
6. The document is amended (or not), "ready for approval" is changed to "Yes! Go!", which restarts the workflow.
7. Tricia completes the task, responding "approve"
8. Cassy completes the task, responding "approve".
9. The document checks in, approval status is changed to "approved".
So, I still want all approvers to complete the task. It sounds like Flexi-task might not be the correct action but I'm not sure what would be instead.
One solution could be to set a maximum number of approvers and create a column for each one "approver 1", "approver 2" and so on. Then a flexi task is created for each one. I've seen a simliar template workflow so could use that for reference.
Cassy Freeman Enrico Knapp hanne andersen
Hi
If you choose "all must agree on a specific outcome" and choose "approve" then that should work this way.
approver 1: approve
approver 2: approve
approver 3: reject
>>> will go down the "other" branch
approver 1: reject
approver 2: not required
approver 3: not required
>>> will go down the "other" branch
if you put what you would put in your reject branch in your other branch you should be good to go.
The only problem here is if you want to know approver 2 and approver 3 responses even if approver 1 rejects - that won't work with this.
Look at this awesome blog post by