Fieldcode Manual

Tip: You can use filters for better results

Container tickets are primarily designed to handle rollout projects or device setup services.

A rollout project is usually a project with a bigger effort compared to just tickets with just one particular overall problem/task.
A rollout project in general requires service delivery to a whole location or department and requires one or more engineers and one or more appointments
in the process of delivering the service. This process normally requires more organizational efforts, than a standard ticket can deliver.

Additionally, to more organizational effort, you would also create more effort for the ticket system. For example, you suddenly require a lot of tickets regarding one big overall task because you need to roll out a lot of hardware, and software installations, or update installations at once to a whole department with a limited amount of time. Dispatchers, therefore, would need to assign tickets for every device the engineers need to install – and for an office with let’s say 100 employees – dispatchers would also need to create 100 separate tickets for this task. You can just imagine that this is not practical at all and a very manual and effort task. Container tickets will simplify the work for the dispatchers in this special use case and that’s also the use case where our new container tickets functionality really shines.

The container ticket is a superordinate ticket that can handle multiple appointments and engineers without the need to create separate tickets.

Appointments are handled inside the superordinate ticket 
(inside the Intervention tab of the Ticket Details). The dispatcher will see the appointment with a reference to the superordinate ticket inside the Timeline component. The major key difference to a standard ticket is that the dispatcher may assign multiple appointments and multiple engineers inside the Scheduling Assistant. Engineers also resolve tickets as usual inside the Fieldcode Mobile App, with the addition of the possibility to create child reports for more than one device/problem that the engineer resolves within one particular appointment.

Use case

The IT Corporation needs to roll out 20 new company laptops for their small new office in Nuremberg. The project is called "Device Rollout NBG Office 1". The project is handled by the two engineers McNiell and Smuthers and dispatcher Miller is the dispatcher in charge. Both engineers have different skill sets, Smuthers has more talent for hardware installations and McNiell has more talent for software installations.  The project needs to be completely resolved in two days and the IT Corporation, therefore, opens a matching ticket. Instead of now opening 20 different tickets, just one ticket is required for the job. The container ticket functionality is therefore capable of saving a lot of organizational extra effort. As a result of the ticket request dispatcher Miller decides to plan the mornings for the hardware and the evenings for the software installations inside the Scheduling Assistant. Dispatcher Miller is quite happy that he will be able to successfully solve this project, as the container ticket functionality gives him enough flexibility and freedom to freely schedule multiple appointments with multiple engineers and multiple interventions.

Container tickets are normally integrated into the standard ticket process

However, there are some key differences compared to default tickets:

  • Appointments are nested inside the container ticket and changes are done for the appointment itself, rather than the ticket.
  • Appointments will show in the Timeline, referencing the container ticket number.
  • Container tickets cannot be moved back to the Ticket Pool.
  • Drag & Drop is disabled for container tickets (Ticket Pool->Timeline, Timeline->Timeline, Timeline->Ticket Pool).
  • Each appointment inside the container ticket has dedicated workflow buttons.
    They apply only to the appointment - not the container ticket.
  • Changes applied to a ticket apply to all appointments.
    We rather suggest you to make necessary ticket changes before the appointment gets scheduled to avoid potential data inconsistencies.
  • The container ticket moves to the next proposed status (eg. PENDING WAIT ONSITE) when all appointments are fixed!
  • The container ticket stays on the current status until all appointments are either canceled or reported
  • If at least one appointment of the container ticket is PUBLISHED the EDIT and CANCEL TICKET workflow buttons are disabled.
    The ticket stays in its current status.
  • If all appointments are UNPUBLISHED the EDIT and CANCEL TICKET workflow buttons are enabled.
    The ticket moves back to the previous status.

The container ticket is a superordinate ticket that can handle multiple appointments and engineers without the need to create separate tickets.
Appointments and engineers are handled inside the superordinate ticket (inside the Intervention tab of the Ticket Details).

No, this is currently not supported.
For this case we recommend to cancel the container ticket and create a new ticket instead.

By default all roles have the option to convert tickets to container tickets. 
There is no special configuration required inside Fieldcode Admin Panel concerning the utilization of container tickets.

Rollout projects

For example a company needs to rollout a bigger amount of devices a at once.

Project requirements:

  • 20 Workstations need to be unpacked, installed, and configured at desks on-site at the customer location.
  • Project has a tight deadline, must be completed within two days.
  • Three engineers are in in charge for the project.
  • One of the engineer only works half-day.
  • Another one of the three engineers needs to travel half-day to reach the customer location.
  • Serial numbers and the assigned employees are required for all device setups.

Device Setup Service projects
For example a hospital needs medical device setup services.

Project requirements:

  • Technicians are sent to set up devices in course of 4 to 5 days.
  • Technicians need to set up 8 to 10 setups each day.
  • They do not want to schedule each setup individually since it is the same resource on the same location and it’s a fluent process.
  • The project requires the assignment of multiple engineers to a ticket.
  • The project requires to split a ticket to multiple onsite interventions.
  • The project requires that the onsite times are adjusted for each technician individually.
  • The project requires to have reporting enabled for each singly device in scope.

Container tickets are able to meet all those different requirements and circumstances. 

  • Container ticket – superordinate ticket – displayed in the Timeline – displayed in the Ticket Pool
  • Container ticket appointment – displayed in the Intervention tab – displayed in the Timelinenot displayed in the Ticket Pool
  • Child ticket/report – Subordinate ticket – not displayed in the Intervention tab (only in the child ticket itself) – displayed in the Ticket Pool (if RESOLVED)
  • Standard ticket – displayed in the Timeline – displayed in the Ticket Pool

No, this is currently not supported.
Optimization of container tickets is currently not supported.

The child report is behaving like a regular ticket report, the only difference is that you handle multiple devices inside an appointment and report each.
The child report can be done by the engineer or dispatcherA child report can become necessary if a engineer handles more than one device inside an appointment. The engineer would then create a child report inside his mobile application before closing the whole appointment for the day with the subordinate report. Child reports appear as resolved tickets inside the Ticket Pool.

Dispatchers can report additional child appointments and the whole appointment for a day (UNPUBLISHED APPOINTMENTS).
Engineers can report additional child appointments and the whole appointment for a day (PUBLISHED APPOINTMENTS).
Child ticket reports will appear as RESOLVED child tickets inside the Ticket Pool.
-> Please be advised that closing whole appointments inside the Fieldcode Mobile App also closes the possibility to add child ticket reports.

Absolutely!
You can tailor the child ticket report form to your specific business needs inside Fieldcode Admin Panel -> Forms.

It might be the case that your container ticket overlaps with another ticket in the Timeline.
In this case it is important to know, that your ticket is not lost, and you can still find it in the Ticket Pool and work with it regularly.

Let's go through the lifecycle of a container ticket to see how it compares to a default ticket in order to get more familiar with the usage container tickets:

Container tickets and the system
  • Project assignment remains a purely manual action done by the dispatcher.
  • It is not possible to optimize container tickets.
  • Container tickets cannot be moved back to the Ticket Pool.
  • Drag & Drop is disabled for container tickets (Ticket Pool->Timeline, Timeline->Timeline, Timeline->Ticket Pool).
  • Handling parts inside container tickets is currently not advised, but possible. 
  • Automated actions always take the last appointment as a reference, therefore we currently advise you to exclude container tickets from automated actions.
    Please check the workaround further below.
  • Conditions for container ticket take the last appointment as a reference, therefore we advise you not to use the appointment fields in conditions for container tickets for now.
    If you still decide to use them, they will always take the last appointment of the interventions tab as a trigger.
    Affected monitored fields: Dispatch appointment start time, Dispatch appointment end time, Fixed appointment start time, Fixed appointment end time
    What would that mean for my condition?
    Let's say you have a container ticket with three appointments (01.01.; 06.01.; 12.01.)
    If you use an condition here, the condition would only alert you at the last appointment.
  • Indications always take the last appointment as a reference, therefore we advise you not to use the appointment fields in indications for now.
    Affected indication: Too many unsuccessful attempts to repair!
    If you still decide to use them, they will always take the last appointment of the interventions tab as a trigger.
    What would that mean for my indication?
    Let's say you have a container ticket with three appointments (01.01.; 06.01.; 12.01.)
    If you use an indication here, it would only indicate/alert you at the last appointment.

If your company workflow heavily relies on automated actions, there is a workaround available to exclude container tickets from the automated actions.
This way you can still use all your other existing automated actions without losing the benefits of automated actions.

  1. Inside Fieldcode Admin Panel go to Automated Actions.
  2. Select the impacted automation in the list.
  3. Click on the Filters tab.
  4. You manually add the following filter to every already existing automated action:
    Condition – Operator – Value
    isContaineris equal toFalse
  5. Automations should now have no effect on container tickets – however – they will still apply to regular tickets.
    With this workaround, you can keep all your current automation without unwanted consequences!
  6. Click on SAVE after configuring the filter.
  7. Repeat step 1 to 6 for other automations in the list!
    Be advised that maybe not all automations in the list need this workaround – it mainly effects automations where appointment calculations happen.
Applying the workaround
Was this topic helpful?
5 out of 5 stars

1 rating

5 Stars 100%
4 Stars 0%
3 Stars 0%
2 Stars 0%
1 Stars 0%
5
How can we further improve this topic?
Please submit the reason for your vote so that we can improve this topic.
Navigation