Ticket Setup
Ticket Setup controls the dropdowns, rules, forms, timing promises, email intake, help text, and suggestions used by tickets. Set this up carefully before real tickets start coming in.
Administration sidebar note: the app also has a standalone Departments page and a standalone Team Directory page. Ticket Setup still explains how those records affect ticket rules and routing.
Departments
Departments represent teams such as Support, Billing, Technical, HR, or Finance. Tickets are routed to departments, users can belong to departments, and reports/automations use departments for filtering.
| Field | What It Means | Example |
|---|---|---|
| Name | The team name users will see in ticket forms and filters. | Billing Support |
| Description | Optional explanation of what the team handles. | Handles invoice, payment, and refund questions. |
| Active | Whether the department should be available for new work. | Turn off an old department instead of deleting it. |
The departments index follows the shared table pattern from usage/table-usage.html. Row selection checkboxes should appear only when a real selectable or bulk action exists; otherwise users work from the normal row actions.
Categories
Categories describe the type of work. They help the app suggest priorities, apply custom fields, match FAQ entries, and report on issue types.
| Field | What It Means | Example |
|---|---|---|
| Category Name | The issue type shown on tickets. | Access Issue, Bug Report, Refund Request |
| Sort Order | Controls where the category appears in lists. Smaller numbers appear earlier. | 10 for common categories. |
| Auto Department | If selected, tickets in this category move to that department when no specific agent is manually chosen. | Billing for Refund Request. |
| Auto Assigned Agent | If selected, tickets in this category go to that agent by default. Leave blank when team routing should decide. | Send VIP Refund tickets to a senior billing agent. |
| Description | Internal explanation of when to use the category. | Use for login, password, and permission problems. |
Priorities
Priorities describe urgency. They affect queue attention, SLA policies, automations, escalation rules, and reports.
| Field | What It Means | Example |
|---|---|---|
| Priority Name | The urgency label users select on tickets. | Low, Normal, High, Critical |
| Sort Order | Display order in dropdowns and lists. | 1 for Critical if you want it first. |
| Priority Level | Numeric urgency level from 1 to 99. Higher can mean more urgent depending on how your team reads it. | 90 for Critical, 10 for Low. |
| Display Color | Hex color used for badges and visual scanning. | #B42318 for Critical. |
| Active Option | When off, the priority remains in history but is hidden from new ticket selection. | Deactivate an old Medium-High option. |
| Default Priority | The priority automatically used for new tickets when no other default is supplied. | Normal |
| Description | Plain guidance for when staff should use the priority. | Use Critical when production is down for many users. |
Statuses
Statuses show where a ticket is in the workflow. They also control close behavior and SLA pause behavior.
| Field | What It Means | Example |
|---|---|---|
| Status Name | The workflow label agents see. | Open, In Progress, Waiting On Customer, Resolved |
| Sort Order | Display order for lists and boards. | 10 for Open, 90 for Resolved. |
| Display Color | Badge color for quick scanning. | #16866A for Resolved. |
| Active Option | When off, the status stays in old tickets but is hidden from new status choices. | Deactivate an unused QA Pending status. |
| Default Status | The starting status for new tickets when no other default is given. | Open |
| Closed Workflow Status | Marks tickets as completed or closed. Closed tickets are locked from normal edits. | Closed |
| Pause SLA | Stops SLA timers while the ticket is in this status. | Turn on for Waiting On Customer. |
| Wait Reason Code | Explains why time is paused. Options are waiting on customer, waiting on vendor, and on hold. | waiting_on_vendor |
| Description | Guidance for staff on when to use the status. | Use when the customer must send more information. |
SLA Policies
SLA policies define the support promises. The app matches policies by department, category, and priority, then calculates response and resolution deadlines.
| Field | What It Means | Example |
|---|---|---|
| Policy Name | Name of the promise or rule. | Critical Technical - 1 Hour Response |
| Sort Order | Order used when showing or evaluating policies. | 1 for most specific policy. |
| Active Policy | When off, the policy stays in history but does not match new or recalculated tickets. | Turn off an old contract policy. |
| Department Scope | Limits the policy to one department. Blank means any department. | Technical Support |
| Category Scope | Limits the policy to one category. Blank means any category. | Outage |
| Priority Scope | Limits the policy to one priority. Blank means any priority. | Critical |
| Response SLA (minutes) | How many minutes until first meaningful response is due. | 60 means respond within 1 hour. |
| Response Warning (minutes) | How many minutes before the response deadline the app should warn staff. It must be less than or equal to the response SLA. | 15 warns 15 minutes before breach. |
| Resolution SLA (minutes) | How many minutes until resolution is due. | 1440 means resolve within 24 hours. |
| Resolution Warning (minutes) | How many minutes before the resolution deadline the app should warn staff. It must be less than or equal to the resolution SLA. | 120 warns 2 hours before breach. |
| Use Business Hours | When on, SLA time only moves during configured open hours. | A 4-hour SLA opened Friday evening may continue Monday morning if weekends are closed. |
| Description | Human explanation of the promise. | Applies to urgent production issues for technical support. |
Example: If Response SLA is
120 and Response Warning is 30, a ticket created at 10:00 should be answered by 12:00, and staff see a warning at 11:30.
Ticket Tags
Tags are labels used for filtering, reporting, automation, and quick understanding. They can be added manually or matched automatically by keywords.
| Field | What It Means | Example |
|---|---|---|
| Tag Name | The label staff see on tickets. | VIP, Needs Evidence, Refund |
| Sort Order | Display order in tag lists. | 20 |
| Display Color | Badge color for the tag. | #155E95 |
| Active Option | When off, the tag stays on old tickets but is hidden from new selection. | Deactivate a campaign-specific tag after campaign end. |
| Auto Matching Enabled | When on, keywords can automatically add the tag to tickets. | Turn on for refund keyword matching. |
| Keywords | Words or phrases that trigger automatic tagging. The app trims duplicates. | refund, chargeback, payment failed |
| Description | Guidance for using the tag. | Use when the customer is asking for money back. |
Custom Fields
Custom fields add extra structured information to tickets. They are useful when normal fields are not enough.
| Field | What It Means | Example |
|---|---|---|
| Field Name | The label shown on the ticket form. | Affected Employee ID |
| Field Type | The input type. Options are Text, Textarea, Number, Select, Multi Select, Date, and Checkbox. | Use Date for incident date. |
| Sort Order | Order in the custom fields area. | 10 for the first custom field. |
| Department Scope | Show the field only for a department. Blank means any department. | Show Invoice Number only for Billing. |
| Category Scope | Show the field only for a category. Blank means any category. | Show Browser only for Bug Report. |
| Placeholder | Example text inside the field before the user types. | Example: EMP-1042 |
| Options | Choices for Select and Multi Select fields. | Chrome, Firefox, Safari |
| Required Field | When on, the ticket cannot be submitted without a value for this field. | Require Invoice Number for refund requests. |
| Visible In Public Forms | When on, requesters can see and fill the field in public support and portal forms. | Show Order Number to customers. |
| Active Field | When off, the field stays in old ticket records but is hidden from new forms. | Turn off an old survey field. |
| Help Text | Short instruction under the field. | Enter the employee code shown in HR system. |
Custom Field Type Examples
| Type | Use When | Example |
|---|---|---|
| Text | The answer is short. | EMP-1042 |
| Textarea | The answer needs multiple lines. | Steps to reproduce a bug. |
| Number | The value must be numeric. | 2500 |
| Select | The user should choose one option. | Browser: Chrome, Firefox, Safari. |
| Multi Select | The user may choose more than one option. | Affected modules: Payroll and Attendance. |
| Date | The answer is a calendar date. | 2026-05-06 |
| Checkbox | The answer is yes/no. | Urgent approval needed? |
Mailboxes
Mailboxes let email create tickets. An external parser or email service posts parsed email data to the inbound mailbox endpoint and proves it is trusted with a secret token.
| Field | What It Means | Example |
|---|---|---|
| Mailbox Name | Friendly name for this mailbox setup. | Main Support Inbox |
| Inbound Address | The email address this mailbox represents. | support@example.com |
| Inbound Secret Token | Password-like token used by the inbound email endpoint. It is required when creating a mailbox. On edit, leave blank to keep the current token. | long-random-token-123 |
| Active Mailbox | When off, inbound email payloads are not accepted for this mailbox. | Turn off during migration. |
| Default Department | Department used when the email payload does not provide one. | Support |
| Default Category | Category used when the email payload does not provide one. | General Inquiry |
| Default Priority | Priority used when the email payload does not provide one. | Normal |
| Default Status | Status used when the email payload does not provide one. | Open |
The app generates and stores a mailbox key, and stores the token as a hash. Inbound services authenticate with X-SupportHub-Mailbox-Token.
Reply Templates and FAQ Entries
Reply templates help agents answer faster. FAQ entries power smart suggestions and the public knowledge base.
Reply Template Fields
| Field | What It Means | Example |
|---|---|---|
| Template Name | Internal name for the reusable reply. | Password Reset Instructions |
| Sort Order | Display order in suggestion results. | 10 |
| Active Template | When off, the template remains saved but is hidden from suggestions. | Deactivate an outdated policy reply. |
| Department Scope | Only suggest the template for one department. Blank means any department. | Technical Support |
| Category Scope | Only suggest the template for one category. Blank means any category. | Access Issue |
| Priority Scope | Only suggest the template for one priority. Blank means any priority. | Critical |
| Keywords | Words that help the app suggest this template. | password, reset, login |
| Template Body | The message content agents can reuse or edit before sending. | Please try resetting your password using this link... |
FAQ Entry Fields
| Field | What It Means | Example |
|---|---|---|
| Question | The question or article title. | How do I reset my password? |
| Category Scope | Limits the FAQ to one ticket category. Blank means any category. | Access Issue |
| Sort Order | Display order in lists. | 20 |
| Active Entry | When off, the FAQ is hidden from suggestions. | Turn off an outdated answer. |
| Publish In Help Center | When on, the FAQ can appear in the public knowledge base. | Publish a general password reset FAQ. |
| Keywords | Words that help match tickets to this FAQ. | forgot password, login |
| Public Summary | Short preview text shown in public listings. | Steps to reset your account password safely. |
| Answer | The full answer shown to agents and, if public, to customers. | Step-by-step reset instructions. |
Business Hours and Holidays
Business hours and holidays tell the SLA system when support time should count.
| Field | What It Means | Example |
|---|---|---|
| Day Label | Name of the weekday row. | Monday |
| Open | Whether support works on that day. | Open Monday to Friday, closed Sunday. |
| Start Time | Time business hours begin, using 24-hour format. | 09:00 |
| End Time | Time business hours end. It must be later than start time. | 17:00 |
| Holiday Name | Name of a closed or exception day. | Eid Holiday |
| Holiday Date | The date of the holiday. Each date must be unique. | 2026-05-27 |
| Holiday Active | When off, the holiday record remains saved but does not affect calculations. | Deactivate a cancelled holiday. |
Example: If a policy uses business hours and support is open 09:00 to 17:00, a ticket created at 16:30 with a 60-minute response SLA is due at 09:30 on the next open business day.
Delete Rules
Setup records are protected when active tickets, SLA logs, issue groups, mappings, or other dependent records still reference them. If deletion fails, deactivate the record or move dependent records first.
| Record | Why Deletion May Fail | Safer Action |
|---|---|---|
| Category | Tickets, issue groups, or SLA policies still use it. | Create a replacement category and move old records first. |
| Priority | Tickets or SLA policies still use it. Default priority cannot be deleted. | Deactivate or choose a new default first. |
| Status | Tickets still use it. Default status cannot be deleted. | Move tickets to another status first. |
| SLA Policy | Tickets or SLA logs still reference it. | Deactivate instead of deleting. |
| Custom Field | Ticket values still reference it. | Deactivate the field to preserve history. |
| Mailbox | Email tickets still reference it. | Deactivate it after migration. |
| Tag | Tickets still have mappings to it. | Remove mappings or deactivate the tag. |
| Reply Template or FAQ | These can usually be deleted because they are reusable content records. | Deactivate first if you may need history. |