Slate DevLog: Internal Ticket System

I feel like a rite of passage as a Slate captain is to have to figure out how to manage a large volume of internal tasks/requests. I’ve seen this at a few institutions where they reach year 4–5 of their implementation and the number of users, along with their ideas, increases exponentially. I say that lovingly because that just means you are earning buy-in from the campus and making great strides in improving archaic processes. The problem is, you will have to make some choices on what should be prioritized because you (and your team) can’t do it all. So how do you get yourself organized to ensure that the most urgent issues are being resolved first and there are no other requests getting lost in the shuffle?

I thought it would be helpful if I walked through my own building process, from end-to-end.

Note: This write-up is more about the ideas that pieced this project together instead of the actual development side. I do use a lot of out-of-the-box Slate features and only really have custom code for some UI design.

Determining the Structure

Custom Dataset

Lots of directions you can go here. You can actually just have a Slate form with some internal updateable admin fields and that should work well enough, but I wanted a set-up that’s a bit more robust. I currently work in an instance that is shared across multiple departments so it was a big priority for me to set something up that allows the flexibility to add custom fields and do some reporting and tracking. Ultimately, I decided that this would live in a custom dataset, with each ticket being its own dataset row.

Messages and Comments

A common problem that occurs when you’re working in a shared instance is that one team member may have resolved an issue by making a change that ends up affecting another part of the instance. I wanted the ability to store/send messages and leave comments for our future reference so when we need to track down a change, we can find it.

To handle this, I ended up creating a separate entity that is scoped to our ticket dataset. With a Slate entity, we can create new rows for every message/comment that is exchanged which basically serves as a pseudo audit-log.

Automated Assignments

Another feature that I wanted is to assign tickets to the appropriate staff member depending on the nature of the ticket. For this, I created fields for the ‘ticket type’, ‘staff assignment’ and the ‘department’, each scoped to our ticket dataset. There are form rules that populate the staff assigned field based off of the ticket type and department selected in the request form. To give you more context, here is the ticket types that we are currently using:

• Student Record
• Query/Reporting Help
• Feature Request
• User Permissions
• Communication Request
• Other

The idea here is to be able to assign tickets to staff members based on what they’re comfortable with. This also gives us the ability to analyze some pain points that we may need to improve upon. For example, if we are getting a lot of requests under ‘Query/Reporting Help’, do we have to reinforce our training? If we have a lot of ‘Student Record’ tickets, is there something going on with our automation that is causing some sort of discrepancy?

Centralized Dashboard (Portal)

Working in a shared instance, requests can end up in a lot of different staff’s inboxes and there’s no way of knowing who’s looking at what or what the status of it is. We want to remedy that by having everything live in one central portal/dashboard. With this portal, staff can submit their ticket, view the status of it, send messages and also go back and review old requests as well. The operations team uses the same portal, but they have a specialized administrative view for processing.

To summarize:

1. The data for the ticket itself is stored in the dataset.
2. Any additional details (mainly comments and messages) are stored in a linked entity.
3. We then take all that data and display it in the dashboard.

And here’s a visual representation of the schema.

Processing the ticket

Slate Forms

With this ticketing system, we just have two Slate forms that handles the following:

1. Requesting the ticket
2. Updating details (messages/comments)

Both of these forms are embedded within our tickets portal. We have queries on the back-end to pass through parameters onto the form that grab the user info so we know who submitted the form and we know which ticket to link the updates to.

Communications

The benefit of using Slate forms is that we can also leverage the automated communications. Between our two forms, communications are set up on the following triggers:

1. Ticket Request Confirmation
2. New Message
3. New Comment (operations staff only)
4. Status Update

Workflow

Putting all of those pieces together, the workflow looks something like this:

The chart above is just illustrating everything that happens on the back-end in terms of what data gets stored and how emails get triggered.

There’s a lot going on behind the scenes but this is where the design of the portal comes into play. I wanted something that was straightforward and easy to navigate where users didn’t have to worry about all of that back-end processing. They can just provide their updates by filling out forms and move on. This is actually the main reason why we decided to build a custom system instead of using other third-party software such as Zendesk or JIRA. Both are great products but they tend to be geared more towards those that work in IT roles. Slate usually deals with many more staff members that work outside of that realm, so simplicity is key.

All that being said, here is a demo of our dashboard:

Closing

This ticketing system has been in place for a little over 2 years and it’s gone fairly well. I haven’t needed to overhaul the structure and the staff has gotten pretty accustomed to going to the portal for all of their Slate maintenance needs. By nature of this system, we are building a nice repository of past issues that we can analyze or refer back to.

Has it increased efficiency? I’d say so — although I don’t really have a tangible metric that I can point to for proof. As of now, we have a 28% YTD increase in tickets submitted. Just looking at that number you may say that there’s more work. It’s hard to say if it’s actually more work since we never had any prior tracking, but I will say that I spend less time digging through old emails and more time on adding features and improving what we’ve already built. So my counterpoint is to say that I’m doing more of the right work.

Additional Resources

My situation is certainly not unique and there are plenty of other Slate users out there who tackled this same topic. The Slate preferred partner ReWorkflow was generous enough to compile all related resources which can be found HERE.

I also recommend looking at the slides from the 2022 Summit presentation ‘Utilizing Slate for Process Management’ by David Carroll and Chris Holsten at Bentley University. I had actually JUST gone live with my ticketing system when I attended so I was curious to see how mine would compare. During the development process, there was a lot of questioning whether I was going down the right path. I didn’t really have a point of reference so it was incredibly validating to see that a lot of my approach aligned with theirs.