Linear Approvals

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.

Subtask Approvals

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.

Fields:

Each Subtask will have an approver field.

Actions:

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.

Components:

Fields:

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

Decision:

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.

Form/Transition overrides:

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.

Javascript Multi Approvals

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.

The count threshold version instead of checking whether the field is empty or not on the decision checks if the binary field named threshold is set to yes (it is defaulted to no). The approval form checks if the number of original possible approvers minus how many are yet to approve is equal to or greater than the number of required approvals you have set in the javascript. In this case care must be taken to make sure it is only used in a process where at least this number of approvers will be entered in the field on any given item.

The percentage threshold version instead of checking whether the field is empty or not on the decision also checks the threshold binary field on the decision as above. In this case the binary is set via javascript to yes when the number of people who have approved divided by the number originally available to approve is higher than the percentage set in the javascript (via decimal rather than percent, E.G. “.75” rather than 75%. In this case care must be taken to make sure that the percentage used makes sense with the number of users expected to be entered, for example 90% of 4 users is all 4.

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.

Similarly to the binary approvals app you can add a transition that denies the approval, sending the item back to a state where the submitter owns it to re-work and re-submit it for approval. In this case the javascript on the submit that copies the original approvers user field to the yet to approve user field should be run so the approvals restart once they re-submit. This saves on items in the database instead of creating a new item each time.

Components:

Fields:

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.

Decision:

Checks if anyone is left on the Approvers Not Yet Approved field, and if there are sends it back to the waiting approvals state, if not, the item moves into the workflow as approved. In the case of the threshold by count or percentage versions this instead checks whether the binary field “Threshold” has been set to yes by the javascript.

Javascripts:

In the forms for each type of java script multi-approvals are the javascripts needed as form actions. Percentage of and count of have numbers that can be changed depending on the desired threshold. The 0.75 in percentage of, for example, represents 75% approval. In the count of version the variable number is the 3.

Form:

The form must have the fields called by the javascripts as shown in the example process app. Some are hidden on form load, and shown then written to on form submit.

Process app type: Design Example

Required SBM Version: 11.2

Complexity: Advanced