Using Categories

Changing a category to another one that does not simply expose different fields but also changes the field properties (default setting, available list values, Required setting) is not recommended, since existing data in such fields cannot be updated. We recommend the following best practices:

Additional ticket categories should be created for multiple independent workflows when there is no chance that one type of ticket or device will need to be changed into another.

EXAMPLE  You may want to use tickets for customer service requests, engineering change orders, and employee on-boarding. For each workflow, completely different fields are required. Devices require different UDFs for tracking a router than an Office 365 license.

The category should expose all fields and contain all options for your users to do their jobs. Forcing them to manually change the category to gain access to certain fields or options will lower productivity, not raise it.

Instead, edit your Standard ticket category and organize the fields in collapsible sections that follow your ticket workflow. As you or different team members work on the ticket, expand and collapse sections as needed.

EXAMPLE  Create sections for Triage and Assignment (Queue, Resources, Issue, Sub-Issue), Ticket Work (SLA, Due Date, Estimated Hours, Device), and Billing (Contract, Service/Bundle, Work Type, Purchase Order Number).

When you create a ticket category, you can also control which other categories it can be changed into (when in Edit mode) and viewed as (when in Detail mode). You do this by editing the Available List Values for this Category in the Header section of the General tab.

Remove all categories this category should never be changed into, and ensure that the field properties either remain the same or are expanded by the new category. Use a workflow rule to change the category.

EXAMPLE  When the ticket status is updated to Ready for Billing, the category is changed to Ticket Billing. All fields remain the same, but the billing fields are now added.

If your security level includes access to other ticket categories, you can view the ticket using a different category's layout without modifying the ticket's actual ticket category. This will give you access to fields that may be hidden on the original category.

You will not be able to change the ticket category at all if one of the following applies:

  • Your security level has a specific ticket category selected for the Render all Tickets as Ticket Category setting. Refer to Render all Tickets as Ticket Category:.
  • You are assigned a Co-managed Help Desk security level, and a Ticket Category Override was selected for you.

If your tickets or tasks are assigned to co-managing users (internal IT or contractors), or internal security is a bigger concern, you have the option to tie a security level to a specific ticket category. All tickets a user with this security level will be viewing is then displayed or rendered as this category, no matter what the actual ticket category happens to be.

To take advantage of this feature, you would develop your ticket categories in tandem with your security levels.

  • Each security level would have a corresponding ticket category that would expose all fields and options users with this level would ever have occasion to touch.
  • Rarely used fields could be put into a section that can mostly stay collapsed.
  • Fields that users with this security level cannot view or edit would be hidden.

In this scenario, all tickets would be assigned your Standard ticket category, and it wouldn't change. But each security level would see the ticket through a custom lens, with different fields and options exposed.

There are a couple of caveats:

IMPORTANT  Users with these security levels would not be able to change their viewing category, should this ever become necessary.

IMPORTANT  At the same time, the display category is not a security feature, because on lists and tables, additional fields might be exposed.