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
In the case of many processes an approval by several different persons working for one and 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 about granting parallel approval via pop-up window
The basic construction should be implemented in such a way that every user will receive a message via a pop-up window. This new window should provide each user the option to decide wether the process should be approved. If some users may have disapproved the process during this selection procedure, then the process should take a different direction than if there had been an unanimous approval. For this to be successfully implemented the model has to be designed 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. Together with the call of selectusersbygroupbyclass at maximum three drop-down menus can be edited in such a way that up to three users can be selected to give approval. |
| 2 | To assign the corresponding Swimlanes to the selected group members this VariableAssignmentActionHandler has to be used. At this script node three Swimlanes can be dedicated for the three aforementioned users “Approval User 1-3”. |
| 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 variable 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 ProcessVariableSetter can be set up at the script node to generate a process variable. This process variable may then adopt the value rejected. This process variable will be again important at a later stage regarding Element 6. |
| 5 | An Actionhandler does not necessarily have to be set up at this particular node. Although, the node may for example be combined with the GenerateIdentityProcessVariablesHandler to store data written by the user and which then is supposed to be sent as a PDF ((WordTemplateHandler). |
| 6 | The VariableExistsDecisionHandler can be used at this Exclusive Gateway to check if the process variable encountered at the earlier stage 4 has in fact been properly set up. 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 the 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 write down any reasons for a rejection.
The new HTML elements will have to be designed as mandatory fields to ensure that a selection has been made and reasons for the rejection provided. To accomplish this the HTML attribute has only to be amended by entering required=“true.
The process will then have the following design:
The red-colored area is the field in which a check will be conducted if any of the elements in the Smartform has 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 using the VariableDecisionHandler (formerly known as the SmartFormDecissionHandler).
