Share:

As a preparation for this tutorial it might be useful to work through the basic tutorials in the Quick Tutorials - Learning Basics in 15 Minutes project. In this project, you can find 2 tutorials to learn the basics about modeling a process and workflow. After you did the tutorials it will be much easier for you to work through this tutorial. For that reason, it is expected that basic skills are existent and therefore will not be explained in this tutorial. 

In this topic, it is given 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.

Information 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.
Mail 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
The start event needs to be configured as an External Event, and for the available business entities option please select the already configured workflow variables. There is no further configuration necessary. 


Setup (Sub-Process)
This contains several elements which are used for the preparation of the main process. 

Start and End
These events are automatically displayed when a sub-process is used. 


Determine name/email of modeler (Get Active Directory Property)
These activities are used to get the name and email of the user who modeled the process to approve. The output data of these activities are stored in workflow variables.
Store username of modeler (Assign Value)
This is quite a simple activity where the username is stored in the ModelliererUser workflow variable. 
Publish process model (Publish Model)
Before a process is approved or the decision is made whether it should be approved or not, the process is always published first, in order to have the possibility to display the process over the Process Portal which will be needed when reviewing the process. 

Create link to the process model in the process portal (Assign Value)
After the publication has been made, the link for the process in the Process Portal is now generated.

Create SharePoint entry (Add Business Entity Item)
The SharePoint list has to be extended by the new entry of the currently running approval.

Create display and edit links for SharePoint entry (Assign Value)
Now there is one more thing left to prepare, which is the generation of the links for editing and viewing the previously added entry in the SharePoint list.


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. 




 


If you need an example of how each activity can be configured then check out topic Activity Documentation



Previous |  Next