Rolling out categories

When we analyze customer Autotask instances, we find that often, way too many users have Admin permissions. And everyone who has Admin permissions for an entity can create, edit, and delete entity categories.

NOTE  BEST PRACTICE: Navigate to > Admin > Organization Your Autotask instance may be configured to use one of the following terms instead: Account, Business Unit, Client Company, Customer, Site. Settings & Users > Resources/Users (HR) > Resources/Users (HR) > Security section > Security Levels and review the Admin settings for each security level. Refer to Admin security settings.

All remaining Service Desk, Project, and CRM administrators should form an implementation group that determines all things the categories will have in common.

The result of the group's work should be a modified version of the Standard categories that are optimized for your local organization The database record of your own organization in Autotask. It has the organization ID "0", and is used as the sender address on quotes, invoices, etc. Previous versions of the help referred to this database record as: 0 Account, Zero Company, Your Own Company..

Priority and Status colors are shared by all task and ticket categories.

Color plays a important role in the elevation of certain information. Priority and Status fields now appear on colored badges that convey the priority and status even without reading the text. Color associations are global settings, and you should consult with all other admins in your local organization before you assign colors.

Here are a couple of ways to go about it:

• Use warm and cold colors for Priority. Red denotes urgency; blue, serenity.
• You have 34 colors to choose from. Use colors that match your local organization logo.
• Don't use more than five or six different colors, because your users will not be able to remember what they mean. You may have 47 Task & Ticket Statuses, but instead of assigning every status a different color, group them together into the following groups: New, In Progress, Escalated, Waiting, Complete. If you have three Waiting statuses (Waiting Materials, Waiting Customer, Waiting Vendor), assign them the same color, but use a different icon for each.
• Another option would be to assign status colors based on the associated SLA event.
• Distinguish status and priority by assigning primary colors to priorities and pastel colors to statuses.

Refer to Task & ticket priorities and Task & ticket statuses.

All existing data will initially be assigned the Standard category, which is designed to display the same information as the old form it is replacing. We recommend that you keep the Standard category because it displays all entity fields and selector options, but this does not prevent you from optimizing it for your local organization.

To customize this Standard category and save it as your Organization Standard, do the following:

Hide unused fields

Hide all system and user-defined fields your local organization doesn't use.

Review section names and order

The Standard category retains the section names of the old forms. 

EXAMPLE  For tickets, that would be the following: Ticket Information, Assignment, Device Your Autotask instance may be configured to use one of the following terms instead: Asset, Configuration Item, Installed Asset, Installed Product., Billing, and User-Defined Fields.

You can now:

• Rename the sections

• Reorder the sections

  NOTE  Consider creating a section called Required Fields and moving it to the top of the Details panel.

• Remove sections

  EXAMPLE  If you don't associate devices with tickets, you can hide the Device field and remove the section altogether.

• Create new sections
• Move fields, including UDFs, from one section to another
• Hide fields. For the implications of hiding fields, refer to Implications of hiding fields.

Refer to Sections & Fields.

Group existing UDFs

UDFs tend to be added over time by different users and departments:

1. Find out which person, group, or department is using each UDF. Inactivate UDFs for which ownership cannot be established, except for UDFs of type ATEDataMapping, which are used with RMM integrations.

2. Then add an owner prefix to each UDF name and, in the Description field, enter the department, group, or title of the person who owns the UDF. If a UDF is shared by more than one group, use a prefix like ALL or don't use a prefix.

   EXAMPLE  HR - Job Profile or IT - Onboarding

3. Create a section for each group of UDFs and order the sections and the fields within sections by either the frequency of use or the workflow order.

You can create up to 100 categories for each entity. But generally speaking, fewer and broader categories are easier for everybody. Consider the following:

• The more categories you have, the harder it is for users to remember how to use them
• The more a category is tailored to one specific workflow, the less it can be used by other user groups in your local organization
• Different categories hide different fields, which will prompt users to change the category. Each time this is done manually, you are prompted to decide whether to apply the defaults of the existing category or the new category.

Most likely, you will want to create a category for each owner of UDFs, whether that is a person, team, or department. But you should also consider categories for groups that need to display fewer, not more fields. These groups may not have created UDFs and may up to now not even have used tickets or tasks.

NOTE  Best Practice: Start with a few broad categories and add more narrow ones as needed. Categories can be shared easily when the total number of fields is manageable or the fields are grouped into sections that some users have collapsed, a setting that is now persistent.

Create categories that support an entire workflow

Each category can have different defaults, selector options, and hidden fields. While you can change the category, this can lead to complications when categories are designed to support a very narrow workflow. Values may change in fields that are hidden by the new category. It is generally preferable to make available all the fields that are necessary for a given workflow and avoid manually changing ticket categories.

Collapse, don't hide

Because fields can be organized in custom sections, you can have a clean interface and still make rarely used fields available. Just put them into a section called Rarely Used Fields and place the section at the bottom of the Details panel.

While creating your standard categories should be the result of cooperation between all Administrators, in this next step, each Admin will take responsibility for the creation of any group-specific categories.

NOTE  To create additional ticket categories, leverage the work you have done creating your Organization Standard ticket category.

1. Create a copy of your Organization Standard category for each user group and name it after the department, group, or activity it will be used for. Refer to The context menu.
2. On the Details tab, hide all UDFs and system fields that are not used in any of the group's workflows and delete empty sections. Refer to Sections & Fields.
3. On the Insights tab, move insights to the Visible or Hidden group, as appropriate. Refer to The Insights tab.
4. Since in this step, you are creating categories for specific workflows, it may be appropriate to create Checklists and select a default for each category. Refer to The Checklist Library.

Once your categories are established, refining them is an exercise in removing options that are not used in the group's workflows.

For each category, you can do the following:

• Establish default values for many fields. Default values allow you to populate hidden fields.
• Determine if a field is required. Required fields that are hidden must have a default value.
• Limit the available selector options to a subset of all values. If the field type is List, you can select which options will be available for this category.

Refer to Configuring field properties.