MyZapp

Set up the ticket reference data

Available in en es fr

Updated on 10/25/2026

The reference data gathers the lists every Service Desk ticket relies on: categories, statuses, types, impacts, urgencies, priorities and resolution codes, plus the status transitions and the priority matrix. You set it up from the Service Desk settings menu entry, which opens the Service Desk administration screen on the Categories tab. These screens are restricted to Administrators and Service Desk administrators.

Names are entered in each active language of Portail ZAPP: only the default language (required badge) is mandatory; a language left empty shows the name in the default language.

Categories

Categories classify requests and are used to route them. The Categories tab shows them as a tree, with their Default group and Status.

New category (or the pencil on a row) asks for:

  • Name, in each language;
  • Parent category: "— None (root) —" or an existing category, to create a subcategory. A category cannot become its own descendant;
  • Default routing group: a ticket created in this category is automatically assigned to this group;
  • Icon and Sort order;
  • Offered on the portal: unchecked, the category and its subcategories are no longer offered to requesters on the Support portal (form and list filter); agents can still use it and existing tickets keep it. It is the same setting as the Portal form tab; the category list shows "Hidden from the portal";
  • Active (when editing): an inactive category is no longer offered, but the tickets that carry it keep it.

A category that has subcategories cannot be deleted. A category already used by tickets cannot be deleted either (a message says so): deactivate it to remove it from the lists.

Lookup values

The Lookup values tab holds six lists, one per pill: Statuses, Ticket types, Impacts, Urgencies, Priorities and Resolution codes. New value adds a value to the list shown, with its Name and Sort order.

Statuses have three more settings:

  • Pauses the SLA: while a ticket is in this status, its SLA and OLA clocks are suspended;
  • Scheduling status: the status is offered in a ticket's Schedule screen, for work planned on a given date;
  • Awaiting requester: the ticket is counted in "Awaiting my reply" and can be filtered in the grid, with no effect on the SLA.

A value marked System (the New, Resolved and Closed statuses, which the ticket life cycle depends on) can be neither deactivated nor deleted. A value used by a status transition or by the priority matrix cannot be deleted: remove it from those screens first, or deactivate it. The same goes for a value carried by tickets or by an SLA policy: it cannot be deleted, deactivate it.

Status transitions

A ticket can only move from one status to another if the transition is declared here: the Change status list on the ticket page and the Team board only offer these moves, and automation rules follow them too. Under Add a transition, choose the From status and the To status, then Add. A status cannot transition to itself, and a transition is declared only once. The bin on a row deletes the transition.

Remember to declare the way back you need (for example from Resolved to an open status): without a transition, neither an agent nor the requester can reopen the ticket.

Priority matrix

The Priority matrix crosses impacts (rows) and urgencies (columns). Choose the priority for each cell: every change is saved immediately. When a ticket is created and when its impact or urgency changes, its priority is recalculated from this matrix, unless an agent ticked Priority forced manually. A cell left at "—" gives no priority.

Export and import the reference data

On the Categories tab:

  • Export referential data downloads a JSON file containing the categories, lookup values, transitions, matrix, SLA policies, calendars, automation rules, bulletins, custom fields, macros, variables, tags, escalation policies, OLA targets, correspondence templates (with their content), and the shared saved views and grid queries;
  • Import referential data loads such a file, for example to copy the setup of a test instance. Entries that already exist (same name) are skipped: existing data is never overwritten. The report gives, per family, the number of entries created and already present.

A personal saved view or grid query (shared with nobody) is not exported. In a view, the person-specific criteria (assigned agent, participant, organization) are removed. On import, you become the owner of the views and queries created; a "default" query stays the default only if the instance does not already have one.

On-call schedules are not part of this export.

See also

  • "Define SLAs and OLAs": calendars, SLA policies and internal commitments of the groups.
  • "Add custom fields": extend the ticket form.
  • "Handle tickets": the agents' daily work.
Applies from version 1.0 Verified for version 1.0

Was this article helpful?

Still need help? Create a request