---
title: "Building a Ticketing System"
slug: "building-a-ticketing-system"
updated: 2026-03-18T21:27:31Z
published: 2026-03-18T21:27:31Z
---

> ## Documentation Index
> Fetch the complete documentation index at: https://knowledge.technolutions.net/llms.txt
> Use this file to discover all available pages before exploring further.

# Building a Ticketing System

The best part about building a ticketing system in Slate: it’s in Slate. By putting together a couple of out-of-the-box Slate tools, you’ll be triaging, responding, and tracking support requests, student questions, staff tasks, and more all from the comfort of your own database.

## What are you tracking?

First, identify **who**will submit tickets: students, staff, or external users?

Next, decide the **information** required on each ticket. This might include:

- Requestor name
- Department
- Category, or type of request
- Priority
- Description
- Attachments
- Deadline

Define the **resolution stages** of a ticket. An example:

- Submitted
- Triage
- In Progress
- Awaiting Info
- Escalated
- Resolved / Closed

Finally, assign **responsibilities:**who among your staff triages? resolves? escalates? monitors response time?

## Your menu of options

Now that we know the requirements of the ticketing system we want to make, we can get into the implementation details.

There are many ways to go about it; Slate tools are open-ended and can be fitted together many different ways.

Here are some options:

- **Using a**[**form**](/v1/docs/forms-overview)**:**The simplest ticketing system is just a form. Besides collecting ticket information, a form can trigger communications for follow-up and reminder notifications. If you don’t need a lot of complexity, a form might do the trick.
- **Using a**[**Workflow**](/v1/docs/workflows)**:**Perhaps your ticketing process is more complicated than that: you might need to route a ticket among multiple people, and you might want to give those people opportunities to fill out forms of their own. In this case, you might create a new workflow just for tickets.
- **Using a**[**custom dataset**](/v1/docs/custom-datasets-overview)**:** You might take it one step further and make a custom dataset, where each dataset record represents a ticket, and these tickets are associated with person records. These dataset records can also move through a workflow, and give you the added benefit of allowing more than one ticket to move through a workflow per submitter.

Your choice depends on your requirements and appetite for complexity. Regardless of the route you choose, you can pull ticket data into a report, dashboard, or portal to track time to completion, look at category breakdowns, and more.

## Try our example ticketing system

Don’t feel like building all that out on your own? No problem: we’ve created an [internal support ticketing system](https://community.technolutions.net/get-inspired/post/slate-based-internal-support-ticketing-system-ZGhcGU5adQAcF4h) that you can import into your database and tweak to your liking.

![](https://cdn.us.document360.io/cd8ea7a6-07f3-4846-a554-627ac016d3e3/Images/Documentation/Example ticket.png)

This example uses forms to gather ticket data and collects it all in a dashboard:

![](https://cdn.us.document360.io/cd8ea7a6-07f3-4846-a554-627ac016d3e3/Images/Documentation/Example ticketing system dashbooard.png)

Copy this [Suitcase](/docs/suitcase-import) ID and paste it in **Database → Suitcase Import**to import our pre-made ticketing system:

```SuitcaseID
d2609bbd-56b2-4394-88cf-19ab9b42d4bb:slate-examples
```

### Configuring the example ticketing system

To use this ticketing system, you must configure the following:

#### Internal Support Ticket form

1. Set the status to **Confirmed/Active**.
2. Select **Edit Form**.
3. In the **Assigned To**field (`support_assignee`), add your list of users to the **Prompts**list in the format `Full Name^username`.
4. Select **Edit Communications**.
5. Set **Email Communications**to **Active**.
6. Enter a value in the sender field.

#### Support Tickets portal

Set the portal’s status to **Active**.

## Making your own

Prefer to build your own ticketing system? Here’s how.

This guide lays out the broad steps needed to make a medium-complexity ticketing system consisting of:

- ✏️ **Custom fields, prompts,**and **material types**
- 📝 **A form (or forms)**with which users can submit tickets
- ➡️ **A workflow**where tickets move through bins that represent resolution stages
- 🔔 **Communications**for acknowledgement, reminders, and escalations
- 🤖 **Rules**that assign ownership, change status, and route tickets
- 📊 **A dashboard or portal**in which staff can see tickets relevant to them

> [!TIP]
> ⭐ Best practices
> 
> - **Keep the number of statuses or stages reasonable**: Too many makes the system hard to manage
> - **Ownership should be unambiguous:**Each ticket should have someone responsible for its shepherding through the resolution stages
> - **Set expectations**: So users know what to expect, make response times and stage transition times transparent
> - **Create notifications judiciously**: Avoid overwhelming staff with too many messages
> - **Document your system**: So staff know the meaning of each stage and how to respond

### Step 1: Create custom fields & status indicators

**▶️ Action item:**Create any [custom fields](/docs/custom-fields) you’ll need to collect on the ticket submission form.

Your tickets will start their journey through your system as form responses. These forms will likely need **custom fields**to represent ticket data.

These fields might include:

- Ticket Stage or Status prompt (Dropdown or Single Select) with options mirrored to the lifecycle stages defined in the previous step.
- Assigned Staff / Owner
- Priority
- Due Date
- Last Response Date
- Resolution Date

Optionally [create new material types](/v1/docs/materials-overview) to represent attachments like screenshots.

### Step 2: Make the ticket submission form (or forms)

**▶️ Action item:**[Create a form](/v1/docs/creating-a-form) to capture ticket data.

- Add fields and prompts for all metadata (category, priority, etc.).
- Optionally [allow attachments](/v1/docs/form-palette#material-uploader).
- Configure user access and authentication: internal vs. external, whether they must login, whether form is public via portal, etc.
- Consider adding conditional prompts. Examples:
  - If category is *IT* → display *Computer Type* field
  - If category is *Facilities* → display *Room Number* field
- Otherwise, create a dedicated form for each category.

### Step 3: Set up the workflow

**▶️ Action item:**Create a [workflow](/v1/docs/workflows) for tickets.

- Define [bin settings](/docs/workflow-bin-settings): which users or teams can see or order the bin, which bins feed into which next bins, whether any bins are “locked” or have restricted permissions.
- Automate movement of tickets through the workflow with [bin and queue automations](/v1/docs/workflows#bin-queue-automations).
- Create multiple workflows if different request types follow very different paths, but beware the complexity that arises from many paths.

### Step 4: Automate ticket assignment

**▶️ Action item:**Create [staff assignment rules](/v1/docs/getting-started-with-staff-assignments) to assign tickets to staff or teams based on category or department.

Examples of these automations might include:

- On form submission → Assign default owner / triage group; set status = Submitted; send acknowledgement email
- If status remains in Triage for more than X hours/days → escalate or send reminder
- On change of status to Resolved/Closed → send resolution message to requestor; update *Resolution Date*

Consider also using [populations](/v1/docs/populations) to group tickets by owner, department, or priority, so staff dashboards show what’s assigned to them.

### Step 5: Automate notifications

**▶️ Action item:**Create the notifications you want ticket assignees to receive throughout the lifecycle of a ticket. Create these notifications as [form communications](/v1/docs/form-communications) in the ticket submission form.

For reference, there are four communications associated with our example form:

- **Confirmation:** Sent to the ticket submitter with ticket number, title, and description upon submission.
- **Assignment Notification:** Sent to the assignee when a ticket is assigned (if the "notify assignee" checkbox is selected).
- **Update Notification (Assignee):** Alerts the assignee when a new message is added by the submitter.
- **Update Notification (Submitter):** Sent when a ticket is updated with a new message, status change, or assignment includes key info and directs the user back to the portal.

### Step 6: Visualize ticket data

With Step 5 complete, the remaining steps shift from setup and construction to ongoing maintenance and analysis.

Your options to visualize ticket data are varied. Since we’re working from a workflow, we already have a tool with which to visualize certain aspects of the ticket pathway.

You might also create a standalone [portal](/v1/docs/portals-overview) or [dashboard](/v1/docs/records-dashboards) that present the user with, for example:

- Open tickets by status, category, owner
- Aging tickets (tickets older than N days)
- Number of tickets submitted over time
- Average time in each status

> [!NOTE]
> **💡 Tip:**Ask [Slate AI](/v1/docs/slate-ai) for help constructing queries, reports, dashboards, and portals.

### Step 7: Test and train

Before full roll-out:

- Test the form(s), workflows, and notifications with sample entries.
- Confirm that owners get the tickets, the statuses and stage movements work, notifications are delivered.
- Train staff on how to use the system: how to mark status, reassign, add notes, respond, close.

### Step 8: Monitor and iterate

- Use reports and queries to watch for bottlenecks (for example, tickets stuck in *Triage*)
- Regularly review workflows and stages: do any need modification? Are categories working well?
- Solicit feedback from submitters and staff to ensure clarity and ease of use
- Adjust automations (frequency of reminders, escalation thresholds) based on observed performance