Therefore™ Help

Zoom Window Out
Larger Text | Smaller Text
Hide Page Header
Show Expanding Text
Printable Version
Send Mail Feedback
Save Permalink URL

Tutorials > Solution Designer > Workflow

Workflow: Getting Started

Designing a workflow process in Therefore™ is the last step of a workflow design. Before starting to design the final system it is very important that the customer's business process has been fully understood and optimized for an electronic workflow. It is also important that what should trigger the workflow in Therefore™ is clearly understood.

Every workflow starts with the category. It’s important to fully understand the customer’s business process. While designing the category that will be associated with the workflow, it’s important to consider the information that the workflow will need to progress, and what information will be learned as the document progresses through the workflow. E.g. an invoice may be approved for payment or rejected during the workflow, and an index field noting that status may be desired. Thus, the category design is intrinsically linked to workflow, and both category and workflow must be designed together

Creating a new workflow process

1.Right-click the Workflow object and select New Process...

2.The Process Definition properties window is displayed and new process can be configured.

SD_T_Workflow_New_Workflow_Process_002

3.Select the Mail Notification tab to configure the mail notifications.

Info

•If the mail notifications are not edited, and the Send notifications by Mail checkbox is selected, then the system will send default notification and delegation e-mails. But, for overdue e-mails the recipient must be defined.

•It is also possible to customize these settings for each Manual task in the workflow separately. If this is done, then those settings take precedence and the default mail notification settings are not used. This is useful if you want an e-mail notification to be task specific.

4.When done click OK. Two system tasks (Start and End) will now be visible in the design-pane. If desired, the names of the Start and End tasks can be edited. Double-click on the icon and type in a new name.

SD_T_Workflow_New_Workflow_Process_0056

Adding tasks to a workflow

Once a new process has been created, tasks can be added. The available tasks are separated into three groups.

Manual tasks

A manual task can be basically any function that a user needs to perform. For example, Check this document or Approve this order. In addition to the standard Manual task, there is also the manual Change Category task which requires a user to move the document to a new category.

Adding a new manual task

1.Simply drag the manual task from the toolbar into the design pane. The manual task dialog will open and the new task can be defined.

•On the Assign To tab who the task will be assigned to can be defined.

•The Index Field Permissions tab allows index field permissions to be granted for this specific workflow task.

•The E-mail Notifications tab allows specific e-mail notifications to be defined for this workflow task.

•The Create Document tab allows links to templates to be built into the workflow task.

SD_R_Connectors_Workflow_Workflow_Design_Tasks_Manual_001

Adding a new manual change category task

1.Simply drag the manual task from the toolbar into the design pane. The Change Category task dialog will open and the new task can be defined.

•On the Assign To tab who the task will be assigned to can be defined.

•The Index Field Permissions tab allows index field permissions to be granted for this specific workflow task.

•The E-mail Notifications tab allows specific e-mail notifications to be defined for this workflow task.

•The Create Document tab allows links to templates to be built into the workflow task.

•The Select Categories tab allows the pool of categories to be specified.

SD_R_Connectors_Workflow_Workflow_Design_Tasks_Change_Category_001

2.A manual change category task may not have any proceeding task, it can only go to the End task. It is hence important to give the transition an intuitive name (e.g Please select the correct category), or else the name will be taken from the End task.

info

•A copy of original document can be saved as a old version.

•The user changing the category, can be given special rights to delete the document only for this workflow task.

Routing tasks

These are used to route the workflow and/or to split the workflow into parallel streams that can proceed simultaneously.

Routing a workflow using conditions

Conditions can be used to intelligently route the workflow. For example, a workflow needs to route to different employees depending on invoice amount and department. This can be done by using a routing task, together with conditions.

SD_T_Workflow_New_Workflow_Process_021

Double-click on the transition to open the properties. Click the Macro... button to get a list of all index fields in the category. Choose the relevant index fields and create the condition. See Conditions for more info on SQL statements. After creating all possible conditions, an ELSE condition can be created to cover all other cases.

SD_T_Workflow_New_Workflow_Process_019

Info

For using dependent fields in conditions please see Dependency Mode.

Routing a workflow down parallel paths

Parallel workflow is a powerful feature that enables a workflow instance to be split into parallel paths and then later merged again. This supports the following concepts:

•Splitting into different paths that are processed in parallel. For example, a manufacturing process where multiple tasks need to be completed concurrently.

•A single task that needs to be processed by multiple users. For example, a contract that needs to be approved by multiple managers.

A key element in parallel workflows is the workflow token. When an instance is split, this creates tokens which progress through the workflow. A workflow can have from 1 to n workflow tokens traveling around the process. For a workflow user there is no difference between a token and a standard instance; the workflow inbox will show each task, and claiming a task opens a task dialog as before. The merge task then waits for the configured number of tokens to arrive before merging them back into a single instance.

Parallel workflows can be created using four special tasks. Split, User-split, Merge, and Exception-merge. Each Split must have a corresponding Merge, to ensure that the configured number of tokens are again merged into a single one.

Split and Merge

This first simple example shows how to split a workflow instance into multiple paths using the Split and Merge tasks. In this example we have a contract that is sent to the financial & sales directors for approval, and if it exceeds a value of 100,000, it is also sent to the CEO. The Merge task dynamically calculates how many tokens are outstanding and waits for the appropriate number of tokens (as configured in the merge task settings) to return before merging again.

SD_T_Workflow_ParallelWorkflow_001

It is not necessary, however, that one Split task merges back into a single Merge task. It is possible to merge together different tokens of the workflow instance anytime throughout the process. Each Merge task dynamically calculates what tokens are potentially outstanding and waits until the configured number of tokens arrive back. This next sample shows the same process, but after the financial and sales directors have approved the contract, it needs to go to a proof reader for final error checking. The first merge task dynamically calculates the outstanding tokens and waits for tokens from the finance and sales directors before merging; it "knows" that a third token was created to split to the CEO, but since it is not possible to merge this, it is ignored. Similarly, the final merge task dynamically checks the number of possible tokens that are still outstanding. For contracts under 100,000 it "knows" to only wait for the token from the Proof Reader, but for contracts over 100,000 it waits for the tokens from the Proof Reader AND from the CEO.

SD_T_Workflow_ParallelWorkflow_002

Exception-merge

Next we will look at the Exception-merge which basically aborts all active splits. For example, if the other party in the contract negotiation suddenly decides to stop negotiations, then all other tasks become meaningless and the workflow should end. When an Exception-merge is triggered it "collects" ALL outstanding tokens and merges them. In the example below, the moment the contract is canceled, ALL active tokens anywhere in the process are immediately collected and merged. This means that the workflow tasks will be deleted from the user's workflow inbox and the workflow will proceed to the next task (in our case this is to end the workflow).

SD_T_Workflow_ParallelWorkflow_003

User-split

Finally let's look at the User-split task which allows splits to be assigned dynamically at run-time. For example, instead of creating individual manual tasks for each manager, a User-split could be used that splits the workflow based on users assigned to the manual task after the User-split.

SD_T_Workflow_ParallelWorkflow_004

Looking at the example below, the contract is routed to a User-split which automatically splits the workflow into the required number of tokens as defined by the manual task.

SD_T_Workflow_ParallelWorkflow_006

There is only one approval task, but each assigned user receives an independent token and can work on the task in the same way as with the standard Split task. Once all assigned users have completed the task, it will then be merged again.

SD_T_Workflow_ParallelWorkflow_005

An Exception-merge could also be used, in which case as soon as one manager rejects the contract, all tokens will be collected and the split will be aborted.

SD_T_Workflow_ParallelWorkflow_007

Do's & Don'ts for parallel workflow

1. Every Split task needs at least one corresponding Merge task. In the sample below, there is no Merge task defined, which makes this process definition invalid.

SD_T_Workflow_ParallelWorkflow_Dont_001

2. From within a Split/Merge, it is not allowed to loop back to the Split or a task before the split. Such a loop could lead to new tokens being created unnecessarily.

SD_T_Workflow_ParallelWorkflow_Dont_002

Info

Loops are of course allowed, but they need to be either inside the split/merge or completely outside of it. In the sample below, the loop from Verify to Send for Approval is valid, because it happens completely outside of the split/merge.

SD_T_Workflow_ParallelWorkflow_Dont_003

3. Two merge tasks can never be connected with a transition since each of the two merge tasks will wait for the other to finish first.

SD_T_Workflow_ParallelWorkflow_Dont_004

Automatic Tasks

These are tasks performed by the system that require no user interaction. There are numerous tasks to perform many typical process operations.

Use cases for automatic tasks

•Sending an e-mail

•Starting another workflow

•Waiting for a specified time

•Waiting for specific documents to be saved

•Sending documents for signing

•Changing index data

•Exporting the document

•Converting a document to another format

•Changing a category automatically

•Delete a workflow instance

Transitions between tasks

Transitions allow the workflow to move from task to task. Each transition provides an different route option that the workflow can take.

•Conditions can also be used to dynamically filter the options a user has to complete a task. For example if a manual task has two transition flowing out if it, then the user performing the task will be presented with two options for the finishing the task.

•Transitions can also be used to change the route of a workflow in the event that a task becomes overdue. For example to route the workflow to a manager.