Example customized Workflows

You can customize the Job Ticketing Workflow to be as simple or as complex as you want. Below are some example customized Workflows that you can use as a guide for your own Job Ticketing workflows.

Example: Simple Workflow

At North Shore High, the Office Assistant (Kelly) is responsible for printing forms, notices, tests, and homework sheets for staff. Since the range of print jobs is quite limited, they do not need a complex Workflow. For example, when they receive a printing request, the print room operator can print the job as soon as they are ready as they do not need to provide quotes or proofs. Also, there is no delivery required; the staff member requesting the print run simply picks up the job when it is complete.

North Shore have decided they need only four statuses:

• New
• Processing
• Completed
• Canceled

The configuration file looks like the following:

[
  { "name": "New",
    "type": "New",
    "charging": false
  },
  {
    "name": "Processing",
    "type": "InProgress",
    "charging": true
  },
  {
    "name": "Completed",
    "type": "Completed",
    "charging": true
  },
  {
    "name": "Canceled",
    "type": "Completed",
    "charging": false
  }
]

In this example, the Operator interface workflow looks like the following:

Example: Advanced Workflow

Westface University Print Services would like to modify the Job Ticketing Workflow to suit their normal practices.

Their current process is:

1. They receive new orders via email or in person.
2. They provide a quote and sometimes a proof to the person who placed the order (either via email or in person).
3. The operator adds the order to a hand written daily order list.
4. Operators in the print room pick jobs from the order list and put their initials next to the job to indicate that they are looking after it.
5. When a job is printed, they contact the customer by phone or email to let them know it is ready for collection or delivery.
6. The job is either collected or delivered.

This workflow is very similar to the default Job Ticketing with a couple of minor differences. Since the print room has multiple operators, they want a way to know which jobs are currently being printed so different operators don’t print the same job.

The default template has a status for Ready to print followed by Ready for delivery, but does not indicate which orders are currently being printed. Adding one more status of Printing in between these two statuses, will solve the problem. They would also like to change the name of Pending response to Waiting on response.

The table below shows how their existing process maps to the Job Ticketing statuses.

The configuration file looks like the following:

[
  { "name": "New",
    "type": "New",
    "charging": false
  },
  {
    "name": "Waiting on response",
    "type": "InProgress",
    "charging": false
  },
  {
    "name": "Ready for printing",
    "type": "InProgress",
    "charging": true
  },
  {
    "name": "Printing",
    "type": "InProgress",
    "charging": true
  },
  {
    "name": "Ready for delivery",
    "type": "InProgress",
    "charging": true
  },
  {
    "name": "Completed",
    "type": "Completed",
    "charging": true
  },
  {
    "name": "Canceled",
    "type": "Completed",
    "charging": false
  }
]

In this example, the Operator interface workflow looks like the following:

Next Step: Customize the Workflow