Advanced Customisation: Dispositions

Disposition Maintenance

This screen is allows maintenance of the job dispositions that are used throughout the system. In some cases we may also refer to a job disposition as a job state.

Fields that can be changed:

• Code

(9 character text)

This is the short code for the disposition that is used throughout the rest of the system, and will frequently be entered by operators. The codes should be kept as short as possible. Try to keep frequently entered codes unique after the first or second letter - this way the system can 'guess' it rather than forcing the operator to enter the entire code every time.

• Description

(39 character text)

A human readable description for the disposition that should ideally tell people unfamiliar with the system what the code means. Displayed primarily on reporting screens.

• Priority

(number value 0-9)

The priority of the dispositions is a single-digit number used to sort jobs on the Traffic screens. 1 indicates a high priority, and will tend to appear at the top, while priority 9 jobs are low priority and appear at the bottom. Priority 0 is a special priority for closed jobs - these do not appear on the traffic screen at all.

• Comment Required

(Y or N)

The Comment Required is used to force a comment to be entered whenever a job enters this state. When an operator enters a comment required disposition into the lines on the job maintenance screen, the system will not allow the line to be stored unless a comment is also entered.

• Chargeable

(Y or N)

Whether this is a chargeable job. Jobs are charged for based on the final closed (priority 0) state they are in when the billing report is run. If the final disposition is a Chargeable one it will appear on the billing report, otherwise it will be omitted.

• Colour

(special colour field)

The colour field determines the colour jobs in this state will show as on the traffic screen. Click on the double arrow to change the colour of a disposition.

• Welfare response to apply when state entered

(welfare action code or blank)

If set, a job moving into this disposition will automatically cause a welfare status update for the guard handling the job. This can be used to move the guard to a higher alert level while onsite and in greater danger, and can also be used to report the guard as still safe for routine disposition updates. Welfare status responses can be configured in Welfare Response Maintenance: these responses come through from network J, with error code N and the text as supplied here.

• Prompt for escalation time

If ticked, GDS will prompt the operator for an escalation time when entering this disposition into a job, after which it will escalate the the other disposition specified. A default escalation delay may be specified.

• PDA State Tag

(number or blank)

Dispositions with a number in this field will appear in the list of choices guards have available on their PDAs. The PDAs have a simpler job flow than GDS itself, and this tag number tells the PDA the point in the job at which this disposition can occur.

• PDA status

(Y, N or C)

Indicates whether this status update should be sent to the PDA. Dispositions with a Y value will be sent to the PDA, and if the job is not currently showing on the PDA it will be sent to the PDA as a new job. Dispositions with an N value will not be sent, but if the job has previously been sent to the PDA the guard will still see it on their PDA in whatever the last Y-value disposition was. Dispositions with a C (Clear) value will not be sent to the PDA, and if the job is currently showing on the PDA it will be removed from the PDA traffic list.

• Show on Customer Reports

(Y, N or C)

Indicates whether this status update should show on customer reports. Disposition lines with an N value will not show. Those with a Y value will show, but the comment will appear blank on the report. Those with a C (Comment) value will show along with the comment as entered on the disposition line on the job maintenance screen. This field also controls the states shown to external update users.

• Enter on External Access System

(Y or N)

External access state. Whether this status code is available for external access users to enter into the system from their job maintenance screen.

• Colour on External Access System

The colour that jobs in this state will show with for external users. It may differ to that shown on GDS's traffic screen.

• This disposition is a job resolution

If ticked, this disposition is considered to be a job resolution or outcome. For any job in the system, GDS records the last resolution code that occurred against the job and allows this to be reported on. Use this to identify the primary cause of occurrence in a job: for instance it would mark the state for 'Break in', or 'No cause found', or 'Pet caused activation': the one status line that best describes the job as a whole. You would not normally mark things like 'On site' or 'No further action', as they don't describe job as a whole.

• Resolution alert colour

The colour a job with this resolution will be highlighted in the job history view when dispatching new jobs to the same site. This can be used to bring recent important activity to the operators' attention when they dispatch a job to a site. GDS will only show the highlight if the job has occurred within the duration specified.

• Resolution alert

Describes the action GDS should take if a recent job with this resolution is identified. It can change the colour or also pop up an alert that must be acknowledged before the job can be dispatched.

• Status group

Dispositions can be split into a number of status groups. These groups are used in Status Restrictions maintenance (button at bottom) to control which dispositions may be entered at various points in the job. Typically there will be a status group for each major stage of job handling: when the job has freshly arrived, when a guard has been dispatched, when a guard is onsite and when a guard has completed attendance. More groups can be added by clicking the Status Groups button below.

• PDA order

Determines the order disposition buttons will occur within their group on the PDAs. Higher numbered dispositions will appear first. Where multiple dispositions have the same order value they will be sorted alphabetically.

• Job annotation type

Status lines for statuses with this value set are extracted and highlighted in a separate area on job and incident reports. Use this to allow operators and patrol officers to enter document numbers or identifiers that will show on customer reports.

• Annotation caption

The caption shown on customer reports when an annotation is shown.

• External status

This is the general job status that should be reported to external systems that have access to GDS (typically via the GDS external API). A job may be open (still active), closed (all processing complete), or in a waiting state, where we are waiting for a response from an external organisation.

• Restriction group

Another grouping used in Status Restrictions, this is primarily intended to hide dispositions from jobs in which they cannot occur. In status restrictions you can set up lines that match job type and restriction group, and either allow or disallow the dispositions involved.

Status Restrictions

Status restrictions can be used to determine which dispositions may be entered into which jobs and when they may be entered. They can be maintained in the Status Restrictions maintenance screen, which is available in Maintenance->Job->Status Restrictions, or from a short cut button in Disposition Maintenance.

We use status restrictions to enforce job work flow. For example, when a new dispatch job arrives into the system, we normally want it to be dispatched to an officer. Amongst other things, we'll then expect the officer to arrive on site, perform some tasks and then leave the site - in that order.

We don't want items being entered out of order, and we don't want required items to be missed. In addition, by knowing which items can occur at any point, GDS can offer people a shorter and more relevant list of dispositions to choose from.

The system achieves this by checking the status restriction list at each point where a new disposition may be entered. It looks at what state the job is currently in and works out what dispositions are allowed to come next.

When determining which dispositions can be used next, GDS starts at the top of the status restrictions list and works its way down in order, stopping at the first line that matches. The matching line has an 'allow' or 'disallow' value that determines whether the given disposition may be used. If GDS reaches the end of the list then it defaults to allowing the disposition. Once your setup is mature you are encouraged to put an all-matching 'disallow' line at the end of the list to change this behaviour.

In addition to 'allow' and 'disallow', there are two 'skip' options: the 'skip next' option is special in that if matched, GDS will skip processing the restriction line that follows and then carry on until it finds another matching line. The 'skip next disallow' option will skip all lines up to and including the next 'disallow' line, then will continue processing from the line after that. This allows you to set up default exclusions but pass certain combinations on for further checking.

Each restriction line has a number of fields in it. Only two are required: 'Index', which determines the ordering of the line, and 'Allow/Disallow/Skip next', which determines whether matches will be permitted at this point in the job. All of the other fields are optional - if left blank they will match all values. For each line, fill in only the fields that you want GDS to check.

The fields are:

• start and new status group: the status group the job is currently in, and the status group it will move to if this disposition is entered (see below for more about status groups). A special group, ANY, can be used instead of blank for clarity
• restriction group: dispositions related to certain job types (see below)
• job type: the job type as entered in job entry
• job event: the job event as entered in job entry
• prior status group: matches if this status group has occurred at any prior point in the job. Note that this field is not enforced on the PDAs as they don't have access to the full job history
• customer: a customer code, for setting up special customer-specific handling
• supervisor: this rule only applies to operators in the 'supervisor' user group. Use this to restrict the use of certain dispositions, or the dispatch of certain job types or customers to supervisors. Much as refunds or the sale of some items (alcohol, cigarettes) is double-checked by supervisors at the supermarket, you can enforce similar procedures within GDS.

Status restrictions are held in memory in each running copy of GDS for quick access. They are refreshed as a user logs in, so users currently logged into GDS will not see changes until they close GDS and log back in again. They'll also take effect after GDS automatically refreshes them, around every 30 minutes. A short-cut also exists: if a user selects View->System Status from the traffic menu, GDS will trigger a status restriction refresh in the background.

Status restrictions on the PDAs are assigned as each PDA logs in from the current set on the PDA server. The PDA server refreshes its status restriction set every 30 minutes, or can be forced to do so immediately by viewing View->System Status on the PDA server copy of GDS.

When setting up status restrictions, current best practise is to restrict based on the job type or customer using restriction groups at the top of the restriction list, then enforce the job flow and order using status restrictions further down. This way you can filter the available states based on the job type first, then still take advantage of the generic status ordering that applies to all jobs.

We also recommend that the very last status restriction be DISALLOW, with no conditions on it - that way if none of the prior rules have correctly matched then GDS will disallow the status. This stops us from seeing unexpected statuses in the list when operators are working with jobs.

Some example status restrictions:

```

Start status group=START, New status group=UNCON, Allow=Allow

Start status group=START, New status group=STANDDOWN, Allow=Allow

Start status group=UNCON, New status group=UNCON, Allow=Allow

Start status group=UNCON, New status group=CON, Allow=Allow

Start status group=UNCON, New status group=STANDDOWN, Allow=Allow

Start status group=CON, New status group=CON, Allow=Allow

Start status group=CON, New status group=ONSITE, Allow=Allow

Start status group=CON, New status group=STANDDOWN, Allow=Allow

Start status group=ONSITE, New status group=ONSITE, Allow=Allow

Start status group=ONSITE, New status group=OFFSITE, Allow=Allow

Start status group=OFFSITE, New status group=OFFSITE, Allow=Allow

Start status group=(blank), New status group=(blank), Allow=Disallow

```

A very basic job flow configuration. Allows a new job to be confirmed, then allows it to go onsite, then offsite and finally it can be closed. Note that we allow multiple dispositions to be entered in the UNCON, CON, ONSITE and OFFSITE groups (eg start=ONSITE, new=ONSITE allows us to move from one ONSITE state to another ONSITE state). We also allow stand-down, but only if the guard has not yet arrived on-site. Note

that we have a 'default disallow' policy - if none of the other lines match, we eventually hit the

Disallow line at the end, which filters out all unexpected status combinations.

```

Restriction group=NOISE, Allow=Skip disallow, Job type=NOISE

Restriction group=NOISE, Allow=Disallow, Job type=(blank)

```

Ensures that noise control dispositions are available for noise control jobs (subject to any later rules), but disallow them for any other type of job. Put this at the top of the restriction list so that it is seen before the other more general restrictions. Then in dispostion maintenance, add all

noise-control-specific statuses to the NOISE restriction group. This will ensure that they only appear

for noise control jobs.

```

Start status group=UNCON, New Status group CON, Customer=AB100, Supervisor=YES, Allow=Skip Disallow

Start status group=UNCON, New status group CON, Customer=AB100, Supervisor=NO, Allow=Disallow

```

Allow dispatch only by supervisor for this customer.

Status Groups

Because there are normally too many dispositions to list them all individually in the restriction list, we group the dispositions together based on when in the job flow they occur. Then we can restrict them based on the group each is in instead.

We group the dispositions by putting each disposition into a status group in Disposition Maintenance. You can define the status groups in Status Group Maintenance.

While you're welcome to use any groupings you wish, some of GDS's reporting functions require you to have groups set up so that certain things about jobs can be measured. To use these functions you'll need groups for some or all of:

• the start of the job - before the officer has confirmed receipt. The group might be called START and would contain states like NEW (new job), UN TP (unconfirmed dispatch)
• dispositions for when the job has been confirmed by the officer but they have not yet arrived onsite. A CONFIRMED group would include the CON (officer confirmed job) state.
• dispositions for when the guard has arrived onsite and is carrying out tasks. An ONSITE or DISP group might contain the ONSITE or 10/2 (onsite) state, along with dispositions for tasks peformed and observations made
• dispositions for when the guard is leaving or has left the site. An OFFSITE group might contain the OFFSITE or 10/3 (clear from site) code, as well as dispositions representing things that occur after the job is completed: notify external company and job close
• stand-down dispositions. A STANDDOWN group might contain things like S/DOWN (stand down), SDREQUEST (stand down requested by customer).

Not all of these are necessarily required, depending on which things you wish to measure, but for typical GDS installations all will be present. Suggested group names are above, but you can use any names that you like. You can tell GDS about the groups you have created in User Options->Job Flow. You can also create additional status groups for other sequences that you want to track or restrict.

Restriction Groups

Restriction groups can be used to separate dispositions into groups related to the jobs they will likely occur in. Unlike Status Groups, they won't normally be related to the point in the work flow in which the disposition occurs - they'll normally be linked to job type or event instead.

For example, a security company performing noise control will likely have a set of dispositions related to noise control (e.g. 'excessive noise', 'warning served' and the like). A normal security guard performing an alarm attendance has no need for these dispositions, so by putting them in a 'NOISE' restriction group, and Disallowing dispositions from that group in non-noise jobs, you can ensure that they are seen only when needed.

Restriction Groups can be defined in Restriction Group Maintenance (a button in Disposition Maintenance). You can assign dispositions to restriction groups by setting the Restriction group field in Disposition Maintenance.

Restriction groups are also applied on the PDAs to filter the dispositions available to the guard. Note that the PDAs do have some elements of the job flow built into them (eg jobs are normally expected to be confirmed and the officer is expected to mark on-site and so on), as determined by the status tags. Restrictions mainly affect the list of dispositions the officer sees while on site.