To configure the workflow structure of a task path definition

Parent Previous Next

The procedure to configure the workflow structure of a task path definition is as follows:

  1. Navigate to Quick Menu > System > Cases and Tasks > Task Path Creator. The Task Path Creator window is displayed.
  2. Expand a module heading from the alphabetical list and select an associated task path definition, or enter its name into the Search Task Paths field. By default the list is filtered to show Current task path definitions. An alternative filter can be applied using the Select view drop-down field: Expired, Future or All combinations 1.
  3. Click on Path. The Path tab is activated.
  4. Click on New Version. The New Version window is displayed, ready to create a new 'draft' workflow structure. This procedural step mirrors that covered separately in the topic To apply version control to a task path workflow.
  5. Use the Version drop-down field to ensure that the new variant of the task path workflow structure is displayed.
  6. Using the standard 'drag and drop' technique, systematically transfer building blocks from the left-hand pane into the design area, as part of the desired task path workflow structure. Each building block component performs a specific function within the path, supported by custom characteristics and attributes that are entered in a dynamically-displayed configuration window.
  7. As a starting point, the Task building block is a core component of any workflow structure and characterises a discrete exercise or end user action that must be undertaken as part of the overall case progression activity. Using the standard 'drag and drop' technique, transfer a new Task () building block to the design area. The Configure Task window is displayed.
  8. Enter a task description into the dynamic search field provided, or click on Show All Tasks to bypass the filtering option. All possible matches are returned in the Search Results summary table.
  9. Highlight the row matching the desired task definition to be included within the workflow structure 2.
  10. Enter a Name for the new task instance into the field provided 3.
  11. Using the Calculate SLA from drop-down field, specify whether the target completion framework for the task will be determined from its commencement (Task Start Date), or obtained from a user-defined milestone end point (Milestone Date). Where a milestone end point is chosen, the Milestone building block component must also be specified using the adjacent field.
  12. Where the workflow structure has been defined as a Void Path, activate the Link start date to void date tick box provided, as appropriate, to indicate that the start date for the new task instance will match the commencement of the asset void episode 4. Use the adjacent Void date type drop-down field to steer the derivation of the commencement date i.e. Void Start Date or Count Back from Void Start Date (entering the Days before void start integer value to control the retrospective launch point).
  13. Where the task instance is Mandatory, activate the tick box provided.
  14. To prevent the specific task building block from being reactivated for a reset task path, activate the Do not repeat tick box provided.
  15. Where the task needs to be repeated at a predetermined frequency, activate the Recurrent task tick box provided.
  16. Click on Confirm. The Recurrence Rules window is displayed, ready to define the frequency and duration over which the task should be repeated 5. This requisite step is covered separately in the topic To define recurrent rules for a task component building block. With all configuration steps completed, the new task instance appears in the design area, ready for accurate positioning alongside other related building blocks within the task path workflow structure, together with the logical inter-related connections.
  17. Further building blocks can now be added and positioned within the design area, at the end user's discretion, in any sequence; each additional option is summarised in the table below.
  18. Click on Save.


Note

1 The Search Task Paths field will match against any element of the task path definition description.

2 Only those task definitions matching the workflow structure classification will be available for selection; where a task definition does not permit multiple instances within the same path, once selected it will be omitted from subsequent search results.

3 System validation rules ensure that the name entered for each task building block is unique for the version in current focus.

4 This option is restricted to those task path definitions that have been classified as a Generic Case and configured with the Void Path attribute.

5 This option is only activated in the instance where the Recurrent task attribute has been activated for the task building block.


Building Block

Description

Next Step

Communication

Where a stakeholder communication needs to be dispatched as part of the task path workflow structure, this building block will trigger an automatic or manual communication, as required, with its behaviour and appearance governed by the associated template definition.

This requisite step is covered separately in the topic To add a communication building block to a task path workflow.

Decision

This option applies an outcome check at any point along the route of the task path structure, steering the workflow direction down a particular branch when a possible outcome is met. Channelling the path progression down a conditional branch is controlled using custom criteria constructed within the Advanced Statement Builder.

This requisite step is covered separately in the topic To add a decision building block to a task path workflow.

Complete

As each task path workflow is used to control the progression of an overarching case, the associated stage, category or case file can be set to automatically complete once a particular point along the route has been reached. This building block therefore serves as the end point for a specific branch or workflow termination.

This requisite step is covered separately in the topic To add an automatic completion building block to a task path workflow.

Delay

An optional or mandatory time lag can be introduced into the task path workflow structure in order to, say, adhere to statutory notice periods or to accommodate tenant response opportunities.

This requisite step is covered separately in the topic To add a delay building block to a task path workflow.

Form

As a core component of the task path workflow structure, this building block maps to a generic form template, which in turn is used to gather question responses and observations as a key progression step for an overarching case. Specific values captured within a linked form can also influence the critical path, using custom conditions that are defined within an associated Decision building block. An outcome check applied on any form element response then steers the workflow direction down a particular branch.

This requisite step is covered separately in the topic To add a form building block to a task path workflow.

Milestone

Each key event within the task path workflow structure can be denoted by a signpost - serving as an aide memoir to the end user, indicating that a certain point along the route has been achieved. Similarly, a milestone entry can be linked to a system-generated event, such as the completion of concurrent paths in an ASB case.

This requisite step is covered separately in the topic To add a milestone building block to a task path workflow.

System Action

A number of processes and procedures inherent within Civica Cx Housing and accessible via the standard user interface can now be linked directly to this building block component. Each supported action can be configured with a series of input values, these then being retrieved dynamically at the appointed time from task information fields included within the overall workflow structure. For instance, an 'End Agreement' system action can be defined within the path, which will launch the corresponding data entry form on-the-fly, pre-populated with user input values obtained earlier in the case progression activity.

This requisite step is covered separately in the topic To add a system action building block to a task path workflow.


See related topics...

Understanding the task path creator

To apply version control to a task path workflow

To define recurrent rules for a task component building block

To add a communication building block to a task path workflow

To add a decision building block to a task path workflow

To add an automatic completion building block to a task path workflow

To add a delay building block to a task path workflow

To add a form building block to a task path workflow

To add a milestone building block to a task path workflow

To add a system action building block to a task path workflow

To join building block components within a task path workflow