Benefits: Simplicity of Setup, Perfect for single user approvals.
Drawbacks: Each step must be completed before the next, one could be delayed days as one person is out of office, then by the time the next person gets it they may be out or busy themselves. This can cause approvals to be painfully slow.
Benefits: Flexible, different count of users per item as desired. All approvers can be working on the items at once.
Drawbacks: Denials and re-submittals are more difficult. Many items created simply to approve one. Notes added on approvals will not show on parent item. Individuals may need to add notes or fill fields in multiple items making privileges awkward, or complicated scripts must be written.
Most of the benefits in this case can be achieved with one of the two last methods without the drawbacks or many additional items in the database.
Each Subtask will have an approver field.
Action to move primary item from holding state once all subtasks are completed.
Binary Multi Approvals
Benefits: Fast, transparent, One click, can be used with transitions from notifications.
Drawbacks: Limited by users in fields, 2 fields needed per approval user which makes large numbers difficult. Best for situations where the same few user fields need to approve each item.
Description: Each approval needed will require a binary field defaulted to “no” on submit and a user field. Then a transition is made for each user field binary field pair. The transition should be restricted by to only the user in that field (field in current user) and the binary is set to no. They should be quick transitions. On the transition the binary field is set to “yes”. On the approvals state a button is added to the form for each transition and mapped to them. A click by that user therefor sets their binary field to “yes” and the transition button disappears while no form is shown.
Each of these transitions simply goes to the same transition, where if all binaries are set to “yes” then the item is moved forward in the workflow, if some nos remain as more approvals are required the otherwise rule sends the item back to the approvals state.
A transition to a state where the submitter is the owner can be added in case someone wants to deny the approval, and a transition to that state added from the approvals state. Remember to set the binary fields back to “no” on this transition so all users can re-approve the edited item once it is re-submitted for approval. This is another way to cut down on needless items in the database.
For an example of a fully featured version of this see the scrum team approvals app also available for download.
ApprovedBy1: set to no on submit, set to yes when approver one selects their approval transition, set to no on any transition declining.
ApprovedBy2: same as above for Approver2
ApprovedBy3: same as above for Approver3
Approver1: set to user who will be approving, related to ApprovedBy1, their approve transition restricted by user in this field and ApprovedBy1 being in the no selection.
Approver2: same as above, related to ApprovedBy2
Approver3: same as above, related to ApprovedBy3
Branch rule, if ApprovedBy1, ApprovedBy2, and ApprovedBy3 are all set to Yes, the item moves through to the approved sate, if not it returns to the approvals state to wait the additional needed approvals.
Transitions added to form and mapped to appropriate transition in line with the fields. Restrict by rule added to each transition so approval is only available if the user is in the associated approval field and the binary field associated with same is marked as not yet approved. Transitions for each into the decision state should be quick transitions. Each transition for each approval sets the matching binary field to approved/yes.
Benefits: Flexible user count (E.G. one approval item could have 2 users, the next one 8). Easy to implement. Easy graphical view of progress. Able to set a threshold (E.G. 3 of any of these users must approve/ 75% of these users must approve)
Drawbacks: Needs a transition form. Cannot be done through notification responses.
Description: All users that need to approve an item are added to one field, this field is copied to a yet to be approved field which is used to drive the process. As these users approve the item their name is subtracted from the field, and the field goes through a decision that simply checks if there are any users left in the field. If there are not, the item is transitioned to approved, if there are, it goes back to the approval state to await the additional approvals.
This workflow has a progress bar in each case showing % of the total approvals needed to move forward has been achieved.
A final version which is a yes/no etc. voting application with pie chart is available in the subtaskless voting app also available for download.
Approvers Required Field: Holds all those who will need to approve the item, or in the case of threshold or percentage approved, the total pool of users who could approve. Could be defaulted, filled, or set to be a few other user fields added together.
Approvers Not Yet Approved Field: Holds a copy of the Approvers field, subtracted from one by one as users approve the item, they are removed from the field.
Threshold Field: Binary field set to no on submit. Used only in the percentage and count versions it is set to yes on the approval that sends the item over the percentage or count threshold.
Process app type: Design Example
Required SBM Version: 11.2
Suggested for you are based on app category, product compatibility, popularity, rating and newness. Some apps may not show based on entitlements. Learn more about entitlements.
Multiple approvals possible in one state will speed up your approvals processes. Often there is no need to wait until one individual approves an item before another individual can do the same.
Please upgrade to one of the following broswers: Internet Explorer 11 (or greater) or the latest version of Chrome or Firefox