Business Process Designer

Home > Administration > Business Process Designer

Introduction

The Business Process Designer lets you define and build you workflows that can then be used to standardize and automate your business processes. You can define a logical sequence of activities in a workflow that can then be repeated reliably. The process defined in a workflow can be broken up into a number of stages. Each installed App can have its own set of workflows.

Process Sharing and Visibility

Process owners will be able to view their own processes, and processes which have been shared with them from the Business Process List.

When creating or editing a process it is possible via the Manage Process Settings and Grant Access To option to share your process with:

Roles
Users
Groups - Configured via the Organisational group structure

It is possible to share processes with multiple users, roles and groups. Once a process has been shared, the user will be able to view the process from the Business Process list.

To remove visibility to a specific User, Role or Group simply select the Trash Can icon next to the item you wish to stop sharing the process with.

To enforce the above sharing and visibility controls, ensure the system setting security.bpm_access_controls.enabled is set to On from the administration console:

Home > System > Settings > Advanced

Stages

All Workflow is defined in one or more stages. Stages simplify process complexity by breaking it into smaller pieces. One important rule is that you cannot return to a stage once you have left it. If you reach a condition which would logically require you to revisit previous actions you can build looping or reprocessing inside each defined stage.

Adding a Stage

A new BPM Workflow contains a single stage called 'Stage One'. To add a new stage click on the + next to the list of stages. A new stage contains two nodes; a 'Start' node and an 'End' node.

Stage Properties

The Stage properties can be accessed by clicking on the 'Manage Current Stage' button.

Name - The name is displayed in the tabbed list of stages
Description - Used to describe the purpose of the stage
Checkpoints - defined points within a workflow that act as milestones for the progress

* Checkpoints can be marked as Mandatory or Optional - Mandatory Checkpoints must be achieved before moving onto a subsequent Stage.

Stage and Checkpoint definitions are important considerations. Hornbill's business process workflow automatically builds a Graphical Head's Up Display based on the Stage and Checkpoint names which then represents the process to both the support teams working on the request which the process is supporting, and if enabled on a Service by Service basis, the requester can view the progress through the process via the self service portals, by viewing the stages only, or stages and checkpoints.

Nodes

Workflow is made up of a two or more nodes which have specific process functions. Nodes are connected to each other by lines, which can include branching from outcomes when associated with decision nodes.

Start

The Start Node indicates the starting point of the workflow. There are no parameters and you can can only have one per stage.

Automated Task

Automated Tasks are definable automated actions that will occur within the workflow. The available automated tasks are provided by each application that utilizes Business Process Workflows. Each application can provide automated tasks that are relevant to the application being used.

Authorization

Used to define the decision makers for authorisations, set their approval weightings, add expiry options on the decision, and if required include useful variables from the parent request to assist with the decision making in the authorisation task information. Read More

Decision

These nodes can be used after a number of other nodes including, Human Tasks, or Automated tasks where multiple outcomes are possible. The Decision node can be used to facilitate the drawing of multiple outcome lines to other nodes, and for each outcome to be individually set. It is also possible to join decision nodes, to other decision nodes through the use of a No Match outcome. This caters for situations where multiple outcomes per decision are needed and not simply the three which are available from a single decision node.

Human Tasks

This is for a synchronous manual activity that needs to be carried out. The workflow will wait for someone to update the activity with one of the expected outcomes. You need to define the name and details of the activity, allocate a role or an individual co-worker, and expected outcomes, as well as optionally including variables from the linked parent request which may assist in the completion of the task.

Configuration

When creating a human task it is possible to define this in one or multiple languages, by default this will be English, however it is possible to create copies of the human task in any other languages enabled on your instance. This is a consideration where those who maybe assigned tasks are working in different languages, and they will receive the human task either in the default language or in the language defined in their profile if the human task is configured in the different languages.

Display - This is simply the display name for the human task node in the business process designer, it will not appear on the human task
Title

Title: This will appear as the title on the human task
Category: Set a category which will appear on the human task
Priority: Set a priority to indicate the priority of the task (this is not linked to Service Level Timers)

Owner - The Owner is an important consideration, as they can be notified about the task in reminders, and will also have the ability to reassign the assignee if required. The Owner can be either a named user or a variable

User - Pick from a list of co-workers
Variable - In order to see see a list of possible variables like request owner, you will need to preceed the human task node with the Automated Task Node > Request Entity > Get Information > Request Details

Assign To - Choose who the human task will be assigned to, this can be a named user, group, role or variable.

User - Pick from a list of co-workers
Variable - In order to see see a list of possible variables like request owner, you will need to preceed the human task node with the Automated Task Node > Request Entity > Get Information > Request Details * Lifespan Settings
Role - This will be populated from the default roles and any custom roles defined on your instance. Any Users who are assigned the role will receive the human task, any notifications and will have the ability to complete the human task.
Group - This will be populated from the defined groups on your instance. Any Users who are members of the group will receive the human task, any notifications and will have the ability to complete the human task.* Task Details

Lifespan Settings - It is possible to set a start date, due date and expiry date for the task based on either a predefined value, or based on a variable like respond by or fix by from the parent request.

Start After - Set this to either X Days, X Hours and or X minutes after the creation of the Task, or base this on a variable like log date, resolve by, or fix by. If using the Variable option remember to preceed the node with the Automated Task Node > Request Entity > Get Information > Request Details
Due After - Set this to either X Days, X Hours and or X minutes after the creation of the Task, or base this on a variable like log date, respond by, or fix by. If using the Variable option remember to preceed the node with the Automated Task Node > Request Entity > Get Information > Request Details
Expires After - Expires is a valid outcome for a human task, and setting a value here will allow you to via a decision node following the task allow for branching based on an outcome not being selected but the task expiring.

Set this to either X Days, X Hours and or X minutes after the creation of the Task, or base this on a variable like log date, respond by, or fix by. If using the Variable option remember to preceed the node with the Automated Task Node > Request Entity > Get Information > Request Details

Task Details - Define the details for the human task, this can be a combination of text and if required variables from the parent request which the task is related too, this could be the summary or description fields, custom fields, or even answers to progressive capture questions - see more about inserting request variables here.
Task Options - Decide if you want to display the Time Spent option to the user who is completing the human task
Outcomes - Configure what possible options the user completing the human task can choose from when completing the human task. By default two are provided, Completed and not Completed.

Add Outcomes - Add a new Outcome using the Add New option

> Define the outcome value, a display name, and if the user completing the task is required to provide a reason when selecting this specific outcome.

> Optional provide the outcome a display colour and make the outcome available in multiple languages.

> Apply Settings to save.

Edit Outcomes - To edit any of the above values for an existing outcome click the edit icon next to the outcome you wish to edit
Delete an Outcome - To remove an outcome option click the trash can icon next to the outcome you wish to delete.
Expiry Outcome - It is not required to add a specific expiry outcome, this will be automatically enabled if you have configured an Expires After in the lifespan settings.
Using Outcomes to branch in the business process - If you require different behaviour in your business process depending on the outcome of the human task, use a Decision node directly after the human task and use the outcomes defined in the task as the decision branch options.

End

This stage will terminate the workflow. You can only use this node in the final stage.

Next Stage

This will take you either to the next sequential or a later stage and will only be available when you have 2 stages or more. You cannot go to a previous stage.

Abort

This node will end the workflow and will cause the heads up display to show as red.

Set Checkpoint

This node will allow you to set a visible indicator that a task / or important milestone in the process has been met - In order to use this node, checkpoints must have been defined for the stage of the process (Stage Properties). It is also possible to mark a checkpoint as having been met on the all the above nodes as a configuration option.

Start Parallel Processing

This node can be used where there is a need in a process stage to invoke more than one stream of actions, and for these to run in parallel. Adding this node, will enable multiple process streams to be defined, and these will run independently until brought back together by the Finish Parallel Processing node. An examples of where this would be used, would be where two tasks need to be assigned to different teams, but there is no dependancy or need for one to be completed before the other, so they can be created and invoked in parallel.

Finish Parallel Processing

Use this node to bring together and finish the individual process lines which had been initiated from a Start Parallel Processing node.

Automated Tasks

Hornbill provide a number of automated tasks that are key to any business process flow. An automated task usually has one or more input parameters that need to be provided by the business process designer in order for that task to run. Parameters can be mandatory, optional or can be picked up automatically by the underlying request that the business process is running against.

The options are grouped by areas of functionality and are listed below:

Workflow Failure and Recovery

Under certain conditions it is possible that workflows may fail. Failure of a workflow will be represented by the Head's Up Display on a request turning Red, and will be accompanied by an error message. Typical reasons why a workflow failure may occur include:

Analyst permission rights to perform actions in the workflow
Configuration errors in workflow design
Deletion of email templates, or mailboxes defined in a workflow.

Workflow Recovery

In the event of workflow failure, under certain conditions it is possible to correct the reason for the workflow failure and to restart the workflow from the point of the failure.

Conditions under which a workflow can be restarted

Adjusting analyst rights to perform the action in the workflow which caused the failure - for example rights to send an email from a specific mailbox
Adding an email template which is missing / deleted / misspelt in the workflow definition which caused the failure.

It is important to understand that once a workflow has been created in the admin tool, and the workflow has been started in a request, it is not possible to go back to the workflow, take corrective action and effect the reason for failure on a workflow which is running / In flight. The reason for this, is that as soon as a request invokes a business process, the workflow definition for that workflow is written to the database, and this definition is used.

It is possible to correct data which the process definition is expecting, for example for an email notification, if the process is expecting to use an email template that is misspelt, missing or has been deleted, it is possible to create an email template which reflects the misspelt, missing or deleted value defined in the process, and for the process to be restarted.

In this scenario it is important to correct both the issue for the workflow in flight, but also in the actual workflow which will be used in subsequent requests.

How to restart a failed workflow

In order to restart a failed workflow you will need to be have been assigned the 'Service Desk Admin' role. When you view a request with a failed workflow, you will see a 'Restart Process' button on the Head's Up DIsplay. Without the specified role the restart button will not be visible.

Before pressing the restart button, ensure you have taken the required corrective action.

On pressing the restart button, the process will attempt to be restarted. There are two possible outcomes.

If the process has been successfully restarted, the Head's Up Display will return to green, and a successful restart message will be presented.
If the process can't be restarted, the Head's Up Display will remain red, and a failure message will be presented.

It is possible that the process can't be restarted, or you may have further failure issues which have been invoked once the original failure reason has been resolved. In this case the error message will indicate the source of the failure, and further corrective action may be required before successfully restarting the process again.

In the event of a successful or unsuccessful attempt to restart the process, an email will be sent to the email address specified in the app setting: app.email.restartBPM.feedback in the Service Manger configuration in the admin console. The email will contain the original failure details, if successfully restarted, and both the original failure reason, and the reason why the process can't be restarted if unsuccessful. The email will enable further failure diagnosis.