This is an old revision of the document!
Table of Contents
This page is not fully translated, yet. Please help completing the translation.
(remove this paragraph once the translation is finished)
Description
Often with many processes an approval by several different persons working for the same company is necessary. This page will therefore provide useful tips and guidance on how to facilitate the approval of processes by at least one or more person(s).
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 wether to approve the process. If some users may have disapproved the process during this selection procedure, the process should take a different direction than if there had been an unanimous approval by all users. For this to be successfully implemented the model has to be designed according to the following way:
Explanation of the elements
| Nummer | Description |
|---|---|
| 1 | At this stage, the responsibiliy to assign an approval has to be granted to a distinct group of people. By using the Smartform the membership for this group can be selected. By executing the command selectusersbygroupbyclass a maximum of three drop-down menus can be edited to select up to three users to give approval. |
| 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 for the three aforementioned users. |
| 3 | At this stage it has to be made sure if an individual user should participate in the process by giving his approval. If only two persons are required to give approval 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 in the drop-down menu no corresponding selection has been made 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 again be important at a later stage regarding Element 6. |
| 5 | An Actionhandler does not necessarily have to be executed at this particular node. Although, the node may for example be connected to the command GenerateIdentityProcessVariablesHandler to store data written by the user and which then is supposed to be sent 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 will use the “true” pathway. |
| 7 | At this stage, the process can be changed or extended as desired. |
Rejecting and giving reasons for this via Smartform
If giving reasons for a rejection is supposed to be mandatory this can be done by using the Smartform. To accomplish this, the Smartform has to be amended either by a radio button or a check box or a drop-down menu. In addition, text areas will be required to be able to write down any reasons related to a rejection.
The new HTML elements will have to be designed as mandatory fields to ensure that a selection has to be made and 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 red-colored framed area is the field in which a checkup will be conducted if any of the elements in the Smartform had been assigned the status “rejected”. If this is the case, then the process can be processed correspondingly. Checking the process variables may be done by executing the VariableDecisionHandler (formerly known as the SmartFormDecissionHandler!).
