Tip: Start typing in the input box for immediate search results.
What are container tickets?
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.
The rollout project generally 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.
As a result, you would need more than one ticket to deliver the service because you need to roll out for example hardware, software or updates to a whole department.
Dispatchers, therefore, would need to assign tickets for every device the engineers need to install – and in an office with let’s say 500 employees – the IT would also need to create 500 separate tickets for this task. You can just imagine that this is not practical at all. That’s where the container tickets come into play.
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.
For the engineer and dispatcher, not many changes, he will still see the appointment with a reference to the subordinate ticket inside the components like Timeline.
What happens when a regular ticket is converted into a container ticket?
In Preparation!
Can container tickets be converted back to normal tickets?
No.
In this case, you need to cancel the container ticket and create a new ticket.
What are typical usage scenarios for container tickets?
In Preparation!
How do container tickets behave inside Fieldcode work place?
In Preparation!
Can container tickets be optimized?
It is currently not possible to optimize container tickets.
How are container tickets reported?
In Preparation!
How do container tickets handle the workflow?
Container tickets are normally integrated into the default workflow.
However, there are some differences compared to standard tickets:
- Appointments are nested inside the container ticket and changes are done for the appointment itself, rather than the ticket.
- Therefore each appointment inside the container ticket has dedicated workflow buttons.
- This means: Changes should be preferably done per appointment.
- A container ticket moves to PENDING WAIT ONSITE status when all appointments are fixed!
- A container ticket stays on PENDING WAIT ONSITE status until all appointments are either canceled (would move back to APPOINTMENT)
or reported (would move forward to RESOLVED) - If at least one appointment of the container ticket is published the EDIT and CANCEL TICKET workflow buttons are disabled.
The ticket stays in PENDING WAIT ONSITE status. - If all appointments are unpublished the EDIT and CANCEL TICKET workflow buttons are enabled again.
The ticket moves back to APPOINTMENT status.
Exemplary lifecycle of a container ticket
In Preparation!
Limitations of container tickets
- It is not possible to optimize container tickets yet (but we plan to do it!).
- Handling parts inside container tickets is not advised yet (but we plan to do it!).
- Project assignment remains a purely manual action done by the dispatcher.