Tip: Start typing in the input box for immediate search results.
-
Quick Start
-
- What is Fieldcode?
- Definitions
- What are tickets, projects and workflows?
- How to log in to Fieldcode
- What is the Fieldcode Support Panel?
- What are components?
- What are views?
- How the ticket statuses are defined
- How the ticket colors are defined
- How the Map colors are defined
- Frequently Asked Questions
- Setting up Fieldcode
-
-
Release Notes
-
Short Overview
-
Fieldcode Work Place
-
-
- How to schedule tickets
- How to search for tickets
- How to expert-search for tickets
- How to filter for tickets
- How to grab/ungrab tickets
- How to link & unlink components together
- How to download ticket data as a excel sheet
- How to copy filters/queries for colleagues
- How to email filters/queries to colleagues
- How to assign/unassign tickets to partners
- How to manage spare parts
- How to show tickets on Map
- How to add tickets to the Clipboard
- How to open tickets in a new tab
-
-
- How to use the Interaction buttons
- How to assign/unassign tickets to partners
- How to manage spare parts
- How to use the Workflow buttons
- What is the Communications button (COMS)?
- How to use the Ticket info button (Workflow)
- How to use the Email button (Workflow)
- How to use the Comment button (Workflow)
- How to schedule tickets
- How to use the Remove Pending button (Workflow)
- How to cancel a ticket (Workflow)
-
Fieldcode Admin Panel
-
- What is the Process menu?
- What is the Workflows menu?
- How to create & edit projects
- Automated Actions in the overview
- How to setup custom Automated Actions
- How to setup preconfigured Automated Actions
- How to create & edit conditions
- How to create & edit indications
- How to set up email templates
- How to create & edit ticket durations
- How to create & edit custom fields
- How to create & edit custom forms
- How to create & edit value sets
- How to move stuck tickets via Ticket Workflow Monitoring
-
Fieldcode Mobile App
-
Fieldcode Customer Portal
-
Fieldcode Community
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.