#Jobs
The purpose of this system is to send work items (jobs) to drivers or vehicles, and hence the job is the primary object of the system. A job consists of one or more steps. Each step may optionally list items that it relates to. If jobs are required to be performed in order, then they may be added to a run with mustCompleteInOrder=true. The grouping of jobs into runs is optional, depending on requirements.

Feedback of when a step is completed, or actioned, is returned in the form of "capture"s (which represent the driver filling out a paper record of actioning that step). This is managed by specifying "action"s for a job step. Each action may specify a form, which determines the fields that must be completed to complete that action. If no form is specified, the action may complete “silently” with no further driver interaction. A “trigger” of “arrive-site” may be specified to automatically trigger the action when on arrival at the step’s site.

The mobile devices will have read-only access to the jobs.
##Job Steps
Steps are the part(s) of the job that actually get done. There must be at least one step (or there will be nothing to do in the job, which renders it useless). However, there may also be multiple steps in a single job. An example of this may be where a job represents a consignment or FTL load. Then the steps may be “Pickup” and “Deliver”. There may also be other steps requires such as load checks and weigh bridges. The steps of a job are expected to be done in the order specified.

A metro delivery example could be represented in two different ways:
The truck’s daily “Route/Run” could be represented by a run, with the load a depot and each of the deliveries being represented by a job, each with one step.
The truck’s daily “Route/Run” could be represented by a single job, with the load and then each of the deliveries being steps in that job.

The advantage in the first method is that jobs are the smallest elements that can be updated. So changes to any deliveries can be sent down individually. Hence, additions to the run during the day (or while the run is in progress) are more easily handled. Also in the future functionality, where external users are able to be given access to see status and PODs, it is envisaged that they will be able to see the whole job.

The second method has the advantage of simplicity. Just post in one job with the load and all the deliveries and it’s done.
##Step Actions
The purpose of a step is to be actioned. The purpose of the actions are to display data, capture data captures and eventually “complete” the step. Actions can either evoke a user interface or be “silent” where a capture is created without any further interaction with the driver. Actions without a form element will be “silent”. The purpose of the user interface for the action is either to display information to the driver, capture information from the driver, or both.

##Examples:
there may be an action, that only displays the readonly details of the step to the driver. This may be the default action (what happens when the step is selected from a list). Other actions (to capture data) could then be invoked manually or automatically on arrive/depart.
there may be one view that displays the information to the driver, and well as having fields for him to capture data and complete the step in one action.
By default, actions are manually invoked (by pressing a button). However automatic triggers “arrive-site” and “depart-site” (maybe more in future as required) are also available.
##Driver Job List
What is displayed to the driver in the job list is information from the job(s) and the active (first non-completed) step of the job(s). Clicking on an item in the list will invoke the default action of the active step. If the jobs are part of a run with mustCompleteInOrder=true, then only the first non-complete job will be able to have actions invoked other than the default action, and only that job will create captures.