Activity Updates¶
Activity Statuses¶
An essential concept of dynamic scheduling is that the scheduling problem is continually changing: new activities are created, and existing ones are changing. An activity is, at all times, in one logical status. An activity can change its status to any other status any number of times. The possible status values are defined in the table below.
| Status | Name | Description |
|---|---|---|
| -1 | Ignore | Denotes that the activity is in the system but the Dynamic Scheduling Engine must ignore that activity. This could be for a number of reasons. It may be that further information is expected or that the Activity is currently being processed by the Appointment Booking Engine, for instance. The activity is treated as being unallocated. |
| 0 | Unallocated | Denotes that the activity is in the system but the Dynamic Scheduling Engine has not allocated a resource to do that activity. This could be for a number of reasons. It may also be that the Dynamic Scheduling Engine cannot find a resource with appropriate skills that can answer the activity inside one of the activity SLAs. |
| 10 | Allocated | Denotes that the activity has been provisionally assigned to a resource. However, this activity could be taken from this resource and placed onto another resource's route at any time or even unallocated. This might happen if, for instance, another resource runs early and could now fit this activity into their schedule more efficiently. Alternatively, perhaps a new resource logs on and this activity is the optimum activity for them to perform. |
| 20 | Follow On | Denotes that the split activity has at least one visit committed. Follow on visits are not themselves committed but there are restrictions as a result of the committed visit. The Dynamic Scheduling Engine must use the same resource and can only split or interrupt visits where the constraints allow. Refer to the Scheduling Concepts - Split Activities guide for more information on Follow On visits. |
| 30 | Committed | Denotes that the activity has been finalised to a resource. An activity can only become committed as a result of an instruction to do so from outside the scheduling system. The Dynamic Scheduling Engine will not give away a committed activity to another resource unless it receives an instruction to do so. |
| 32 | Sent | Denotes that the activity has been finalised to a resource, as with Committed, but has now been transferred to an external application (e.g. a field service management system) |
| 35 | Downloaded | Denotes that the activity has been finalised to a resource, as with Committed, but has now been transferred to the mobile device. |
| 40 | Accepted | Denotes that the resource has accepted the activity. The activity remains committed but this provides a positive confirmation that the resource has undertaken to do the work. If the resource rejects the activity then the external application must inform the Dynamic Scheduling Engine by amending the status. |
| 50 | Travelling | Denotes that the resource has started to travel to the activity. An activity can only have status travelling as a result of a resource sending a message to the external application. |
| 55 | Waiting | Where co-requisite activities have been identified a status of waiting is assigned when a resource is awaiting the arrival of another before the activity can start. |
| 60 | On Site | Denotes that the resource has arrived at the location to do the allocated activity. An activity can only have status on-site as a result of a resource confirming to the external application it has arrived. |
| 65 | Pending Completion | This status is treated in exactly the same way as "On Site" status. When sent it is an indicator that the activity could soon be completed. The Schedule Dispatch Service will treat this status differently and activities of this status will not count towards a resource's allowed limit of committed activities. |
| 68 | Visit Complete | Denotes that the resource has completed a visit for a split activity. The activity itself is not complete until the final visit of the activity has had a status update to "Completed". |
| 70 | Completed | Denotes that the activity has been finished by a resource. An activity will only become completed if the Dynamic Scheduling Engine receives an activity completed event from the external application. |
| 80 | Incomplete | A special status to indicate the activity has been carried out, but further work may be required. |
Committed and Uncommitted¶
All activity status values of 30 and above are referred to as committed and those less than 30 uncommitted. When an activity is committed then a resource is assigned to the activity in the plan and the Dynamic Scheduling Engine will not automatically change that assignment. Where it is exactly scheduled could change as the time line moves on but the activity will not be assigned to a different resource by the Dynamic Scheduling Engine. Activities are set to status committed when the activity has been downloaded to a mobile device or the external application wishes to accept that allocation and doesn't want it to change.
When an activity has an uncommitted status, either allocated or unallocated, then this may be changed by the Dynamic Scheduling Engine at any time.
The Dynamic Scheduling Engine will not change a status from uncommitted to committed. Such changes must be passed in from the external application.
Status Ordering¶
The status of an activity is likely to be updated multiple times during it's lifetime. Updates do not overwrite each other, but instead are ordered according to the date stamp on the status row (Activity_Status.date_time_stamp). The latest status update will signal the activity's current status. Earlier status rows may still contain information required by the system, such as the time that a resource started travelling to the activity.
It should be noted that each status update must have at least two dates associated with it, though these may be set to the same value. The date stamp (date_time_stamp) is used for ordering the statuses linked to an activity, while the status date (date_time_status) is used to reflect when the status change occurred in the real world. For example, for a status of travelling the status date signifies when the resource actually started travelling to the activity.