Business Process Designer

Home > Administration > Business Process Designer

Introduction The Business Process Designer let you build and define you workflows 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.

Related Articles Service Manager Business Process Workflow

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 - Where a workflow starts. There are no parameters and you can can only have one per stage.
• Authorisation - 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 Task - 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.
• Automated Task - Container for multiple process actions, which come under both Entity and Application lists. The options are covered in more detail below.
• 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.

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.

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: