How to add Departments in ZenDesk

ZenDesk is becoming the de facto support system but it doesn’t handle departments as obviously as other solutions — this is the missing guide.

What we want to happen

When a ticket comes in (either via email or the web form) it gets moved to the group and has the department’s form added to it. Users in the department have a simple view that shows the its open tickets and it’s all hidden from users outside the department.

The configuration is comprised of a:

1. User Group for granting access
2. Email Address to receive tickets by email
3. Ticket Form to receive tickets via the web and/or show the correct fields
4. Trigger to update a ticket’s group and form
5. Ticket View to display tickets in the group

I’ll assume all these terms are known (or can at least be found in the admin area) and won’t guide you click-by-click, but will explain each step and how it fits into the whole.

Instructions

All changes are made in the Admin area, to which you’ll need access to configure your departments.

1. Create a User Group (Manage > People > Groups) named after the department and add Users who need to access its tickets.
2. Add a Support Email Address (Channels > Email) to receive tickets by email. Feel free to use WHATEVER@YOUR_INSTANCE.zendesk.com — it’s free and requires zero SMTP knowledge!
3. Create a Ticket Form (Manage > Ticket Forms) with whatever fields the department needs. Note that by unchecking “Form name for end-users” you can make the form visible only to your internal users (e.g. for your company’s internal support)
4. Add a Trigger (Business Rules > Triggers) with the following setup to assign the department’s tickets to the correct group and ensure the right fields are shown:
   1. Two rules (matching any) for
      • Ticket: Received at = WHATEVER@YOUR_INSTANCE.zendesk.com
      • Ticket: Form = YOUR_FORM_NAME
   2. Two actions:
      • Ticket: Group = DEPARTMENT_NAME
      • Ticket: Form = YOUR_FORM_NAME
5. Create a View (Manage > Views) with the following setup so the department’s tickets are visible to users in the department and no-one else:
   1. Matching all of the following conditions:
      • Ticket: Group = DEPARTMENT_NAME
      • Ticket: Status != Solved
      • Ticket: Status != Closed
   2. Available for:
      • Agents in group = DEPARTMENT_NAME

Another useful Trigger action is Ticket: Set tags which, when left blank, will remove any tags that are added by other triggers intended for your default support processes that may not make sense for your department.

What Happens

Now, new tickets are moved to the department’s group and its users (and no-one else) can view and work on the department’s tickets. Simples.

You can either setup a department for all activities/products and create a “default” ticket view that looks for tickets without a group (similar to a backlog) or use no group for your main support area (e.g. for your main product) and create groups for secondary processes. For example, tickets without a group could be for client-facing issues and the department setup could be for internal company issues.

Internal Departments

If you want the department to only be visible internally, you can leave the form option Form name for end-users unchecked. In that case, you might not actually need a custom form at all, however some fields are required when a ticket is solved (if the fields is blank, the ticket can’t be closed) and if any of these fields aren’t required by your department but are visible on the default form, you might have a problem!

That’s why I’d recommend creating a new form regardless of the circumstances. If for nothing else, to ensure you have full control over which fields are shown when viewing the ticket.

Note that the Tags field can be hidden globally, but not by department — it’s either visible everywhere or nowhere.

Conclusion

ZenDesk might not be obvious in its support of departments but it can certainly accommodate for them. I suspect this is for simplicity — you aren’t forced to think in terms of departments if you don’t want/need to. However, groups, triggers and views allow so many other setups that it’s probably a blessing in disguise that allows much freedom when you understand how all the pieces fit together.