ASB task management overview
In responding to a reported instance of anti-social behaviour, any number of activities will need to be triggered in order to progress the recorded incident through to a successful outcome. Depending on the details of the incident, any number of separate tasks may be required, and these potentially quite varied in nature. In its simplest form, an anti-social behaviour incident will constitute a single case and the inherent activities - the defined tasks - will be a series of discrete and chronological actions to be carried out by the case owner within a specified timeframe. Naturally, this scenario can be expanded further on a number of different levels. For instance, the required tasks might be quite diverse and spread across different owners with specialist skill sets. Similarly, a single reported incident might transcend a number of different ASB categories, each with quite separate tasks resulting from the nature and complexity of the parent case: the first category capturing, say, a dispute over parking; the second category an escalation of the situation into violent conduct. To maximise the efficient progression of ASB cases, it might be acceptable to progress some tasks in parallel i.e. the completion of one task being independent of another. Conversely, some tasks may be inextricably linked and therefore dependency rules must exist to define the task relationships and any in-built time lags i.e. dictating the commencement of one task in relation to the completion of its predecessor.
Any number of tasks can be created on the system, mapping the constituent elements of all likely ASB case scenarios to the overarching category. These tasks would typically be created in advance, as part of the ASB configuration process, and then linked to different categories, as required. A single task - perhaps generic in nature - can be linked to multiple categories but can only appear once within the same category. In the event that an individual task needs to be replicated within the same ASB case classification, a clone of the original task definition must first be created and added to the category. Simply by adding the task definition to the category workflow, an end user is able to map out the critical path for the progression of an individual ASB case scenario through any combination of tasks. Thus, when a new ASB case is created in response to a reported incident, those tasks linked to the path will be triggered automatically. Naturally, there will always be instances where the specific circumstances of a case demand that additional tasks be included; hence, these can easily be added manually, provided they exist within the category definition.
Before an individual task can be progressed, it must be assigned an owner. By default, task ownership will always be assigned initially to the ASB case owner. However, ownership of a task can also be reassigned at any point to take account of workload, staff absence, specialist skills, etc.
Separate help articles have been created for each key aspect of ASB task management, including:
In addition, separate help articles focus on the progression of ASB tasks, specifically: