A decisoin Step with , decions required:All , if there are 10 different approvers then it needs all(10) approvals and then request goes further processing, its fine and usual functionality of "Decision REQD;All Step". But , how can we achieve , if any one of the 10approvers clicks Need More Info button, then request has to to go to "Rework" staus with out asking or waiting for all the 9 approvers to click Need More Info button. If we use a function possible? how?
I had situation that was similar, though not exactly like this. Our requirement was that at least 3 people from a group must approve a request and if any one of them rejected it, it must go back to a prior step in the workflow. The solution I came up with was to create two hidden fields, approval counter and approver list, and use a single user decision step with some execution steps. The decision step was there and the appropriate security permissions were for the approvers. When one of the approvers clicked on the approve button, it would go to an execution step that would check to see if they had previously approved it. If they had, it returned to the decision with no updates. If they had not, the counter was incremented by one and their username was added to the approver list (this list is what is used for the check to see if they had approved already). Then it moves to another execution step that checks the counter and if it reached the limit (3 in my case), then it would progress to the next step in the process, otherwise it would return to the decision step. Should anyone reject the request or call for more information, the workflow went to an execution step that would clear out the approvers and the counter so that they would have to approve again since vital information in the request may have changed.
The only "issue" with this solution is that the users that have already approved the request will still see that they can act on this request, but any subsequent approvals after their initial approval will not count. With some time and creative coding, I'm sure a solution could be developed to remove that issue, but we were on a tight schedule and this solution worked for the client.
Jason's idea , although complicated, sure sounds interesting, BUT that would totally confuse the users who use the Approval Queue concept (PPM's OOB 'Awating my action' functionality). I know it sure won't work in our case.
I had a similar Requirement & Some once, where I ended up designing a Subworkflow to accomplish the reqiurement.
I know this is not very efficinet idea either but you may be able to get some ideas from this.
But my case was for the Approval Security groups. So we always knew the security would be limited to those 20 + groups that we had. The Groups were cheked in the SWF and respective steps were enabled. and then AND and OR steps were used to accompish the requirements. .. Hope you can get some ideas off of it.
Why are you saying that Jason's approach would not work? I have used the same approach in several implementations and there was basically no drawback to it. And for sure users can make use of the Pending on My Action functionality since all users are responsible in the step.
--remember to kudos people who helped solve your problem
Not saying that it would not work... .. It may ery well could for others. :-)
It just would not work in our case becasue of the way we have our ITG Demand & Change Approval system configured using "Requests Eligible for my Action" property in Portlets which gets reviewed by some CABs and Business owners Daily(may be multiple times) to see if they need to act.
Thats all they do, look and Approve/Disapprove if needed :-) ... If They continue to "See" Approval button, it will drive most of them crazy :-)
The Sub workflow concept that I configured, eliminates that situation as 1 'Disapproval' or 'Need more action' could immediately take the request out of the SWF using OR and route it back to the owner... And when one approves it, it gets out from his/her pending queue and the 'AND' Step waits for others to act on.
This sentence that Jason has mentioned above would be a deal killer in our case: "The only "issue" with this solution is that the users that have already approved the request will still see that they can act on this request".
ok, this is where the difference in my approach vs Jason's comes in.
My approach is as follows: I am making use of a custom field, hidden for regular users, which is populated via an automatic step before the actual decision step. this custom field is configured in field security for the step. Each time any of the x users takes a decision, it is routed to another automatic step which performs the following:
- if the user's decision is to request rework, then the workflow is routed to the rework step.
- if the user's decision is to approve, then the automatic step removes the user who took the action from my custom field and routes the workflow back to the decision step. In this approach, the user who already took a decision will not have the action any more.
The above approach provides more advantages:
- I usually make use of the admin user to dry run the workflows, so in my automatic step I can implement logic for the workflow to follow admin's decision regardless of the number of users who need to act on the decision step.
- the above point is especially useful in production mode, in order to avoid the workflow getting stuck if some user is not providing the approval for any given reason (out of office). This can also be achieved by manually deleting the user from the custom field.
- my approach also allows me to implement even more complex logic, such as "if the majority of the users have approved, then the workflow should move on without waiting for the decision of the rest of the users", or even to weigh the users' decision: "the decision is considered approved if xx% have voted yes" and so on.
- this approach is very easy to integrate with a custom delegation mechanism that you may have implemented in your system.
As I see it, there is virtually no limit to the complexity you can achieve by using the above.
--remember to kudos people who helped solve your problem