Table of Contents
This page is not fully translated, yet. Please help completing the translation.
(remove this paragraph once the translation is finished)
Description
For many processes an approval by several different persons within the same company is necessary. This page will therefore provide useful tips and guidance on how to facilitate the approval of processes by at one to three people.
Decision on granting parallel approval via pop-up window
The basic setup should be implemented in such a way that every user will receive a message via a pop-up window. This new window should give each user the option to decide whether or not to approve the process. If all users disapprove of the process during this selection procedure, the process should take a different direction than if approval had been unanimous. For this to be successfully implemented the model has to be designed according to the following: 
Explanation of the elements
| Nummer | Description |
|---|---|
| 1 | Because the parties responsible for granting approvals typically rotates, the user responsible for granting approval can be selected in this portion of the Smartform. In combination with the selectusersbygroupbyclass cue, dropdowns may be created in which up to three users may be selected and granted approval rights. |
| 2 | To assign corresponding Swimlanes to selected group members the command VariableAssignmentActionHandler has to be used. At this script node three Swimlanes named “Approval User 1-3” can be dedicated to the three aforementioned users. |
| 3 | At this stage a check should be made, in order to see is a user is needed for clearance. If only two people are required to give approval, then the third Swimlane dedicated to the so-called Approval User 3 would not be necessary. The exclusive gateway VariableExistsDecisionHandler can always be used to ensure that a flexible number of people become involved in the procedure. If no selection has been made in the drop-down menu then the task in this Swimlane will not be activated. |
| 4 | The command ProcessVariableSetter can be executed at the script node to generate a process variable. This process variable may then adopt the value rejected. This process variable will be used again in Element 6. |
| 5 | An Actionhandler does not necessarily have to be executed at this particular node. However, the node may, for example, be combined with the command GenerateIdentityProcessVariablesHandler to store data written by the user and then send it as a PDF ((WordTemplateHandler). |
| 6 | The command VariableExistsDecisionHandler can be used at this exclusive gateway to check if the process variable encountered earlier at Stage 4 has in fact been properly executed. If this is the case, then this process continue using the “true” pathway. |
| 7 | At this stage, the process can be changed or extended as desired. |
Noting a justification for a rejection via Smartform
If a justification for a rejection is considered necessary, this can be done by using the Smartform. To do this, the Smartform has to be amended either by a radio button, a check box or a drop-down menu. In addition, text areas will be required in order to note any reasons related to a rejection.
The new HTML elements will have to be designed as mandatory fields to ensure that a selection is made and that the reasons for the rejection are provided. To accomplish this the HTML attribute has only to be amended by entering required=“true.
The process will then have the following design setup: 
The framed area, marked in red, is the field in which a check is conducted to see if any of the elements in the Smartform were classified as “rejected”. If this is the case, then the process can be executed correspondingly. The inspection of the process variables may be performed using the VariableDecisionHandler (formerly known as the SmartFormDecisionHandler).
