This article is an example of how an approval process can look like. Along with the example, a description will be given about how to model such an approval process. But first of all, it is shown how to configure the server, so that the modeled process will be executed if a user clicks Approve, Publish, Reject or Unpublish.
Deposit Process with Configuration of the Server
There are two possibilities to deposit the process so that it is automatically executed when clicking on one of the previously mentioned buttons. But for both numbers, you need the Element ID of the process, because this ID is the one you have to deposit. Either you deposit the element ID in the Registry or in the Configuration Wizard.
Get the Element ID
The element ID can be found when configuring the start event of the specified process model. Right-click the Start event and select Edit event. Under section External event you find the event element ID.
Configuration over Registry
Open the registry and navigate to the path HKEY_LOCAL_MACHINE\SOFTWARE\PROLOGICS\PES\Workflows. There are 4 options where you can set the element ID as the value. In this case, it is required to set the element ID for the ModelGroupId_Approve by double-clicking it. Enter the element ID under Value data in the opened window. For the other three options, an element ID can also be set, even if it should be the same ID for any reason.
Configuration over Configuration Wizard
The other possibility to deposit the element ID is when configuring the server in the configuration wizard. There the element ID can be set under the tab FireStart Server - Optional. At the bottom of the wizard are again the four options to enter the element IDs. For this case, we will need to copy the element ID to the Approval field and click Apply afterward.
Model Approval Process
Each step of the process is going to be explained. For better understanding, the process model is numbered consecutively so that you know which element or activity is currently explained. But before starting to model, a few workflow variables and business entities will be explained.
Workflow Variables
In this example, lots of workflow variables are defined, but one or another might not be necessary. Nevertheless, they all will be explained shortly.
The following variables can be mapped to equally named workflow variables or business entity fields, at the start of the process. The process is started with an external event and provides a number of input parameters which can be stored and therefore can be used during the approval process.
ModelId | This contains the Id of the model to approve. |
ModelName | As the name already suggests, this variable contains the name of the model to approve. |
ModelVersion | Models are filed in versions, therefore, the version of the model to approve is quite important as a different version also means that it differs from another version, and therefore this field consists of the version of the model to approve. |
ModelCreatedDate | The date on which the model to approve has been created is stored in this variable. |
ModelModifiedDate | This variable gives information about the latest modification date of the model to approve. |
ModelType | The type of the model to approve might also be important to know, and thus can be found in this variable. |
UserName | This contains the login name of the publishing user. |
DisplayName | Whereas the previous variable contains the login name of the publishing user, this field contains the name of the publishing user. |
Date | Contains the date of the approval. |
ModelOwner | The owner of the model is stored in this variable. |
ModelOwnerDomain | This variable contains the domain of the model's owner. |
ModelOwnerPath | In addition, the path of the owner of the model can be found in this variable. |
ModelOwnerMail | The mail of the model's owner is stored in this field. |
ModelDescription | If the description of the model is needed somewhere in the approval process, it can be found in this variable. |
ModelUrl | The URL of the model is to be found in this field. |
Contains the mail address of the publishing user. | |
ModelOwnerDisplayName | Contains the name of the model owner. |
Business Entity
There is one business entity needed in the process and it is mapped to a SharePoint list where all approvals will be registered. This list contains some information like the reviewer, the one who modeled the process to approve or the name of the process, etc.
Process Elements/Activities
As already mentioned in the explanation of the process, the elements will be addressed over their number. At the bottom of this topic are screenshots of the entire approval workflow along with the numbering so that you can relate to them.
|
Start |
||||||||||||||
|
Setup (Sub-Process)
|
||||||||||||||
Set process approver (Task) The dynamic user in charge for this task is the modeler, which is stored in a workflow variable anyway, so there is only the assignment to this task necessary. In this task the user in charge has to add a process approver in the SharePoint list, to do that, the task form contains the specified SharePoint link. He only has to click the link and add an approver and then confirm the task. |
|||||||||||||||
Get process approver name (Get Active Directory Property) With this activity, you get the display name of the approver from the active directory, which is needed later in the process. |
|||||||||||||||
Approve process (Task) Now the approver (dynamic user in charge) receives a task where he can decide whether the model should be approved or not. The link to the Process Portal is also part of the task form so that the approver can have one more look on the process. The task form also consists of 2 buttons (Approve, Decline), where the ApproveBool is mapped to them. This enables to store whether it has been approved or declined. This ApproveBool workflow variable is needed for the condition. |
|||||||||||||||
Process approved? (Condition) In this condition, it is checked whether the approver approved or declined the process. The condition consists of 2 possible outcomes which are True or False. This depends on the choice (Approve, Decline) of the previous task. |
|||||||||||||||
Approve process model (Approve Model) If the process has been approved (ApproveBool = True), then the model can be approved with the activity Approve Model. |
|||||||||||||||
Notify modeler about approval (Send Mail) After the approval, the modeler has to be notified about it, so therefore a mail is sent to him. |
|||||||||||||||
Retract process model (Publish Model) If the process approval has been declined (ApproveBool = False), then the model needs to be unpublished, which is executed with the Publish Model activity. The activity has to be configured with the option Unpublish. |
|||||||||||||||
Notify modeler about denial (Send Mail) The modeler will now be notified about the rejection of the approval workflow, using the Send Mail activity. |
|||||||||||||||
End These events do not require further configuration, but they are necessary as a process always needs at least one start and end event. |