Helpdesk projects

Request types, customers and organisations, internal notes and queues.

Helpdesk is the module for serving customers, one of Alba Ticket's five with Projects, Knowledge base, Time and the CRM. A helpdesk project is a project of its own kind: its requests are ordinary tickets with a few things added, its customers can be answered by help articles and their hours invoiced.

A request's path from the customer to the agent, with an SLA clock measuring it Customer portal or public form Request type the form they fill in Request a ticket in the helpdesk Queue a saved view agents work Agent answers public reply: customer sees it internal note: only staff see it updates the request SLA clock starts when the request is raised, pauses while waiting, stops at the first reply; the goal is the target Help articles published pages answer questions on the portal and the form Approvals and satisfaction ratings sit on the request's Helpdesk panel.

This page covers the helpdesk's own parts: request types, customers, internal notes and queues. The customer's side is on The customer portal, and the clocks and approvals on SLAs and approvals.

Note

An administrator can switch the helpdesk off for a workspace (Modules and features). If you do not see it in yours, it is switched off there: ask an administrator if you need it.

Request types

A request type is what a customer picks when raising a request, such as Get IT help or Order supplies. Each maps to a ticket type and carries a form: which fields the customer fills in, which are required, and preset values for hidden fields. Request types are grouped on the portal.

Request types are managed in the project's settings (Settings in its left-edge menu), and through the API and AI agents, by a member whose role has Manage helpdesk forms; project administrators have it. Edit on a request type sets:

  • its name, portal group, ticket type and description, the help text shown above its form, and whether it is hidden from the portal;
  • its form: for the details, the priority and each custom field that applies, whether it is shown, whether it is required, and what it is called on the portal. The fields are asked for in the order of that table, and the arrows beside each move it up or down;
  • who may send the form in: people who can log in, or anyone.

The summary is always asked for, though the form can call it something else, such as Subject. A preset value that an import set for a hidden field is kept and still applied. On the New ticket dialog, picking a request type sets the ticket type for you, and the ticket keeps its request type.

Requests by email

A request type can take requests by email as well as through its form. Give it an Email address in its settings: a word, which becomes the part after the plus sign in the workspace's inbound address (billing makes support+billing@example.com when the workspace receives at support@example.com), or a whole address on an installation whose mail server delivers one. Mail to that address raises a request of that type in the project: the subject is the summary, the new text of the message (not what it quotes) the description, and files sent with it the request's attachments.

Who may write to it follows the form's Who can submit setting. An open form takes mail from anyone, as the public form does: the sender becomes the reporter as a contact, is emailed the link to their request, and gets an account when they first answer, if registration allows it. A form for people with an account takes mail only from an address that could log in, and the request is theirs. The subject is the summary and the message the description, and the request type's preset values are applied as they are on its form; a field the form requires that an email cannot fill is left empty rather than the mail refused, and a preset that no longer fits its field (an option since deleted, say) is left out while the request is still raised. Mail from anyone else is kept under Administration, Email with the reason it was not taken. A workspace that receives no mail yet is set up under Email.

Customers and organisations

Customers are people who raise requests but do not handle them. They are grouped into organisations, and a ticket can belong to an organisation so agents see all of a customer account's requests together. Organisations and their email domains are managed under Administration. A customer sees only the requests they raised and those belonging to their organisations, whatever project role they hold. To let customers raise requests in a helpdesk, add them to the project with the Reporter role; they then see the helpdesk on the portal.

Internal notes

Agents can tick Internal note when commenting, and also on the comment left while assigning a ticket or moving it through the workflow. Internal notes are shown with a badge and are never visible to customers. A customer's own comments are never internal. Ordinary comments are visible to everyone who can see the ticket.

Queues

Queues are saved views of a project's tickets, such as Unassigned or Waiting for support. Open them from the Queues button on a helpdesk project. Project administrators add queues in the project settings by writing the query in JQL: project, status, priority, type, request type, assignee, resolution and customer clauses (customer = "ACME", or organizations as Jira writes it) joined by AND are understood. Anything else in an imported queue is kept for reference and the queue is marked as only partly supported. Sort: SLA above a queue orders it by each ticket's most urgent clock, breached first, so it can be worked in that order; the queue's own order is the default.