Many organizations have a request management process to ensure that desired changes are carried out without disruption. For example, when an IT helpdesk agent gets a request from a user for an upgraded server, there is probably an approval process to decide if there's budget for the upgrade, when it can be carried out to avoid disrupting work, etc.

You can capture your request management process in Deskpro. This article provides a simple example of how to implement a lightweight process, using Deskpro triggers, filters and custom fields.

Required process

This is the example process we're going to implement:

1. Tickets are categorised by agents as None/Minimal, Minor, Major, Emergency.

2. Tickets involving a Minor or Major change need to be approved by a Change Advisory Board (who have agent accounts and are part of a "Change Advisory Board" team in Deskpro).

3. Agents can handle tickets involving a "None/Minimal" change on their own. No need to bother the Board if a user wants to change their desktop wallpaper.

4. Agents can resolve tickets for an "Emergency" change on their own, but the board must be notified.

This is just an example. You can use the flexibility of Deskpro to implement the exact process your organization requires.

Implementing the process

First, we use custom ticket fields (Tickets > Fields) to record the change level and the approval status.

Here's the Change Required field:

We made it an Agent Only Field because users don't get to decide the change level. The level of change might not be obvious at first, so we chose to require a value only when the ticket is being resolved. 

We also make another custom field called Approval status, with the same settings but these values:

When agents set a Change Required value of "None/Minimal", we can automatically set Approval to "Not Required". This is implemented with triggers. First, a Ticket Update trigger:

If an agent creates a ticket and sets the Change Required value straight away, we'll want to do the same thing, so we create an identical New Ticket trigger.

We can create a similar pair of triggers for when an agent sets Change Required to "Emergency". We also want to notify the Board, so we add this action:

This means that the Board get a custom email alert when a ticket is classed as Emergency.

For Minor or Major tickets, we rely on the agents to set the Approval field to "Requested" when the ticket is ready for the Board's attention.

To enable the Board to easily see which tickets require approval, we create a filter like this:

The Board agents can change the approval to "Approved" or "Rejected", and the agent assigned to a ticket will see the change and get a ticket notification.

Agents could also group tickets by Approval to get an overview:

We could also add a Ticket Update trigger to make sure that tickets aren't resolved without going through the approval process:

Now it's easy to see where tickets are in the approval process, and the Board can always see which tickets need their approval.

This is a simple example, but using the same approach you can capture the process your organization needs to follow.