Applies to version 8.3.x and above; Author Kamil Nędza

NOTE: The workflows used as examples in the following article are complex on many levels, and describing them in detail is impossible in a blog-post type article such as this one. The author has decided to present the general concept these workflows to better outline the overall purpose of the solution, and the role that each workflow plays in it – with special emphasis placed on sub-workflows.

When designing business processes, it is often turns out that having one workflow is insufficient to exploit the full potential of your system and employees. Some of the issues encountered are:

1. The need to carry out certain tasks parallel to each other, where working on one workflow instance simultaneously wouldn’t be possible.
2. Access to specific information has to be granted to users individually.
3. The stages of the process have not been divided into smaller logical segments.
4. The hierarchy in the implemented process has to be maintained.
5. Difficulty in monitoring and managing many threads of a process efficiently.

In the following article, I will present two different cases where sub-workflows are employed in WEBCON BPS. In the first scenario, I will build a solution from scratch, which will be used for displaying a recursive list of all related workflow instances, and then their related workflow instances, on the form. The second scenario will be a glimpse at fragment of a larger system, used for managing a marketing campaign. In the second scenario, will also discuss the module used for launching multiple sub-workflows.

Introduction:

By default, the system supports associating workflow instances through a parent-child relationship. Each workflow instance may (but doesn’t have to) have a parent. The child workflow instance stores the WFD_ID of their parent workflow instance in the column: WFD_WFDID.

Fig. 1. Query showing a parent-child relationship

This relationship can also be seen on the SharePoint form, in the bottom left corner:

Fig. 2. Panel showing parent and sub-workflows

The parent-child relationship can have an effect on the workflow logic. WEBCON Designer Studio has the option of adding special steps called Wait for sub-workflows (system step), in which we can define the behavior of the workflow instance that is the parent, based on the behavior of the sub-workflows. Selecting the Wait for sub-workflows as the Step type in the General tab of the step configuration will activate the Subworkflows settings tab:

Fig. 3. Step edit window – ‘wait for sub-workflow’ settings

It is important to remember this relation when designing processes which will feature mechanisms for deleting workflow instances from the database. The System will not allow workflow instances to be deleted if they have any related child-instances.

 

Scenario I – Creating a hierarchal process for managing client relations

Description:

We will create a process consisting of three workflows: Client, Person and Contact. Each Client workflow instance can have multiple persons registered for it. Each Person workflow instance can have multiple contacts. The entire structure should be visible from the perspective of the Client workflow, in an orderly fashion. The final effect should look something like this:

Fig. 4. View of the form on the Client workflow

Configuration:

Start by configuring three workflows with three different form types:

Fig. 5. Workflows and Form types configured in Designer Studio

Next we need to workflow starters. On the Client workflow, add a Hyperlink action (‘Form’ subgroup) that is launched with a Menu button – we named this button New person.

This will create a button on the form menu, clicking the button will launch the hyperlink action – the hyperlink itself has been configured to lead to a blank Person workflow form:

 

Fig. 6. Hyperlink action configuration, set up to start a new Person workflow instance

Notice the PARENT_WFDID parameter. This parameter sends the ID, from which a workflow is started. Thanks to this, a relationship is established between the two workflow instances. The new workflow instance will be registered as a related instance.

Now we need to repeat this on the Person workflow by creating a starter for the Contact workflow:

 

Fig. 7. Hyperlink action configuration, set up to start a new Contact workflow instance

Here is a sample form of a Person workflow instance, which was started from its parent – Client – workflow. It also has one Contact sub-workflow instance:

 

Fig. 8. Person workflow form

It is clearly visible on the screenshot above, that this workflow instance is a sub-workflow (child) of C/2016/04/00001, and that it is a parent for CON/2016/04/00001. By clicking the instance number, we will be redirected to that workflow instance. Please keep in mind, that even though the relationship between workflow instances can be seen by all users who have access to the form – the workflow instances themselves can have their own individual permission settings, and a parent workflow instance may not be accessible to the users of one of its sub-workflows. One workflow instance will always have a maximum of one parent, but it may have multiple related instances in the form of sub-workflow instances (children).

It is time to create a form field which will display a list of related instances. Start by creating a new Data table form field. In the SQL / CAML query field, enter a query which will return data:

 

Fig. 9. SQL Query responsible for displaying data from the workflow

The above query uses a recurring table (Common Table Expression). It lists all related workflow instances in a hierarchal order starting with the current workflow instance. The list is made up from hyperlinks. Clicking one of the will redirect the user to the given workflow instance. With a bit of finesse and a pinch of HTML magic we can add our own icons, thanks to which the final list will look something like this:

Fig. 10. SQL Grid From field for listing existing workflow instances

 

Scenario II – Launching multiple requests for proposals in a marketing action

Description:

We will be discussing a process used for managing a marketing action. The process is comprised of two workflows. The first – Marketing Action workflow – is used for starting and monitoring proposal requests. The second – Request for Proposal workflow – is a sub-workflow of the Marketing Action workflow.  The Marketing Action workflow sends e-mails containing proposal requests to clients, in a way that their reply is not directed to a shared mailbox – instead, it is sent directly to the employee responsible for handling that client.

The workflow diagrams can be seen below:

Fig. 11. Marketing Action workflow diagram

 

Fig. 12. Request of Proposal workflow diagram

An employee starts a Marketing Action workflow instance. From the item list, they select a client name, and the users responsible for them. They then send the workflow instance to the Offer creation step.

Fig. 13. Registration step of the Marketing Action workflow

An employee then clicks the Offer created path. The system will automatically start a task (sub-workflow instance) for each client on the list that will be assigned to the designated user. An e-mail containing an attachment is sent to the client’s address. The e-mail ‘sender’ field is substituted with the e-mail of the designated user – this way, the client will have direct contact with the employee responsible for handling their case.

Fig. 14. Request for Proposal workflow instance being created

Crucial information will be provided to the sub-workflow, so that the e-mail will be sent, and the correct employee will be informed about their new task.

Fig. 15. Request for Proposal workflow instance created successfully

Once the action is finished, the employee may verify whether the marketing action was successful:

Fig. 16. An example of a completed marketing action

Configuration:

On the transition path: Offer created I defined a Start new sub-workflow (SQL) action. In the configuration of this action, select the process and workflow which should be started. In this case, it is the Request a Proposal workflow:

Fig. 17. Action configuration

If it turns out that the number of started sub-workflows is so large (tens or hundred) that displaying them all would clutter the form or make it unreadable, they can be hidden in the Global form template:

Fig. 18. Various options for displaying associated workflow instances

The Advanced tab should fill out automatically based on the parameters you provided in the Basic tab. Finally, let’s go to the Data tab. If you decide not to use the native functionality of keeping the workflows related, it is a good idea to provide the ID of the parent workflow instance to any form field of the sub-workflow instance. On the screenshot below, this ID was saved in the form field: WFD_Attchoose3.

Fig. 19. Action configuration: Data that is sent to the sub-workflows

The configured action is responsible for launching the sub-workflow and providing it with necessary data. The obtained data can be used on a sub-workflow transition path.

On the transition path: Register an action has been configured – Send a custom email. The e-mail is sent to the address stored in a form field. The value of this form field is obtained when the sub-workflow instance is launched.

Fig. 20. Action configuration: Send custom email – Recipients tab

The contents of the message are as follows:

Fig. 21. Action configuration: Send custom email – Message content tab 

Take note of the Sender field. With this configuration, the sent e-mails will have the client’s caretaker listed in the Sender field. If the client is interested in contacting the company, they will be directed to the employee assigned to them.

The last tab is the Attachments tab, in which an SQL query references all attachments added to the parent workflow instance (the one from the Marketing Action workflow). This solution is very efficient and saves disc space, because the attachments physically located on the parent (i.e. Marketing Action) workflow instance only – and it isn’t copied to each sub-workflow instance.

Fig. 22. Query returning ID’s of the attachments located in the related parent workflow instance 

---

Summary

Sub-workflows are a tool with great potential. Correctly implementing them into a business process makes it possible to divide the workload evenly and work simultaneously towards a common goal, it can also help organize the process and make its forms more transparent. There are a great many possibilities and listing them all is pretty much impossible. The solutions discussed in this article are just the tip of the sub-workflow iceberg, their full potential is limited only by the creativity of the system administrator.