Ticket types, flows and statuses
Build the workflow a ticket follows: statuses, flows, entry points and who approves a move.
Who can do thisApplication Administrator
A ticket type points at a flow. The flow decides which status may follow which, and what a move needs. Statuses are shared by all flows.
Statuses
Application ManagementHelpdeskStatuses. Out of the box: New, Open, Waiting on customer (awaits customer), Waiting on us and Solved (end).
Each status has a Name, Color, Type, Pauses SLA and Awaits customer. Type is Open, End (closes the ticket as solved) or Cancellation (closes it as cancelled; only one status can have this type). Type a name, pick a colour and click Add. Use Edit and Delete on a row, and drag rows or use the arrow keys to reorder.
- A new status joins the default ticket type's flow only. Add it to other flows on the Flow tab.
- A status in use cannot be deleted ("Cannot delete: the status is in use").
- Making a status an End status closes the open tickets standing in it and meets their SLA. You are asked first. Undoing it reopens them but does not restore their SLA.
- Making a status the cancellation status adds a move into it from every other status on the flows it shares, so a ticket can be cancelled from anywhere. You can remove those moves one by one on the flow diagram.
- A solved status cannot also be "Awaits customer".
Customers see status names exactly as you write them here, in the portal and on the ticket link page. Choose names that read well to a customer.
Ticket types
Application ManagementHelpdeskFlow, in the Ticket types table at the bottom. The default type is "Ticket" on the flow "Standard". Columns: Name, Flow, Default estimate (min), State (Active or Retired) and Portal.
- Make default: new tickets, including those raised by email, get the default type. The default type cannot be retired or deleted.
- Retire and Reinstate: a retired type leaves the create form, and tickets keep it. A type carried by tickets cannot be deleted, so retire it.
- Changing a type's flow is refused if live tickets would stand in statuses the new flow lacks.
- The Portal settings decide whether customers can raise this type from the portal. See Request forms.
Flows
The flows rail lists each flow, the types that use it and how many open tickets run on it. Use + New flow, Rename and Delete flow. A flow cannot be deleted while a type points at it.
In the designer (Diagram view):
- + Add status opens a palette: Add an existing status puts a shared status on this flow, Create a new status adds it to the shared list and to this flow.
- Drag from a status's right edge to another status to add a move. Click a move to edit its gates: Requires assignee, Requires a comment, Requires approval and Restrict to roles (Administrators, Agents; none ticked means anyone who can work tickets).
- Click a status to edit it, or choose Remove from flow. Removing does not delete the status.
- Tidy lays out the whole flow again. Right-click the canvas for Add status here and Fit to view.
- A flow with no moves lets a ticket go to any status on it. Add moves to enforce an order.
- The designer warns "These statuses have no way out" and asks for confirmation if a change would strand open tickets.
- The Text view gives a read-only, printable description of the flow.
Entry points
Three dashed entry points sit on the canvas:
- (New ticket)
- Where new tickets start: the flow's first status. It cannot be restricted to roles.
- (Agent reply), dropdown On reply
- The status an agent's reply offers to move the ticket to. It is pre-ticked in the reply box and the agent can untick it. Default: "No automatic move".
- (Customer response), dropdown On customer response
- Where a customer's reply lands the ticket: it reopens a closed ticket or moves one waiting in an "Awaits customer" status. The default is Not set, drawn in amber; while it is not set, the reply lands on the flow's first status. Drag its line to an open status, or pick one in the dropdown.
Set a customer response status on every flow that customers' tickets use. That way a reply from a customer always puts the ticket back in front of your team in a status you chose.
Who approves a move
A move with Requires approval needs sign-off. Application ManagementHelpdeskApprovals decides who gives it. Rules are tried in order and the first match routes the request.
- Each rule has an Approver role, a Mode (One approver or Everyone in the role), When priority is and When type is, and can be enabled or disabled.
- The approver roles are Application Administrator and User. Deleting a rule asks, for example, "Delete the rule for Application Administrator?".
- With no rules, the approval goes to one Helpdesk administrator.
- A person cannot approve a ticket they created, unless they are an administrator.
- Everyone who can decide the current step is told at once: a bell notification, and an email if they switched Helpdesk mail on. A request still waiting after one working day sends a daily reminder. See Approve a ticket or a move.