Ticket Types¶
Ticket types define how different categories of work are tracked within the platform. Each type controls which fields are available, what workflows and approval processes apply, how tickets appear to agents and end users, and what lifecycle rules govern the ticket from creation through closure.
Navigation
Configuration > Tickets > Ticket Types on the GRC-ITSM website navigation.
For a description of each ticket type and its purpose, see the Ticket Types reference in the agent guides.
Configured Ticket Types¶
The GRC-ITSM platform comes pre-configured with ticket types supporting both GRC and general ITSM workflows:
| Ticket Type | ITIL Process | Purpose |
|---|---|---|
| Issue | Incident | Security findings, vulnerabilities, and POA&M tracking |
| Vulnerability Deviation | Change | Formal deviations from remediation SLAs |
| Alert | Incident | Security and operational alert triage |
| Change Request | Change | Formal change management with approval workflow |
| User Access Request | Change | Access onboarding, modification, and offboarding |
| Data Request | Service Request | Compliance evidence and artifact collection |
| Incident | Incident | Security incidents and service outages |
| Problem | Problem | Root cause investigation for recurring issues |
| Service Request | Service Request | Routine, pre-approved operational requests |
| Information Request | Service Request | General questions and information requests |
| Project | N/A | Multi-step planned work with child tasks |
These can be customized, and additional ticket types can be created to support organization-specific workflows.
Creating a Ticket Type¶
- Navigate to Configuration > Tickets > Ticket Types
- Click Add
- Configure the Details tab with the ticket type name, ITIL process mapping, and access settings
- Save the ticket type (some tabs only become available after the initial save)
- Configure the remaining tabs as needed
After saving, an Access Control button appears at the top of the screen, allowing you to grant configuration access to specific roles or agents.
Configuration Tabs¶
Each ticket type is configured across several tabs that control different aspects of its behavior.
Details¶
The landing tab when creating or editing a ticket type.
| Setting | Purpose |
|---|---|
| Ticket Type Name | Display name shown throughout the platform |
| ITIL Ticket Type | Maps this type to an ITIL process (Incident, Service Request, Problem, Change). Determines which process-specific features the platform enables for this type |
| Access Settings | Controls who can access this ticket type: agents, end users, portal visibility |
The ITIL mapping determines how the platform treats the ticket. Setting it to "Change" enables change control features like approval workflows and scheduling. Setting it to "Incident" enables incident management features like escalation to problems.
Defaults¶
Defines what happens automatically when a ticket of this type is created.
| Setting | Purpose |
|---|---|
| Initial Status | The status assigned when a ticket is first created |
| Default Team / Agent | Who the ticket is assigned to by default |
| Default Category | The starting category |
| Default Priority | The starting priority level |
| Default SLA | Which SLA policy applies |
| Default Workflow | Whether a workflow auto-starts on creation |
| Default Approval Process | Whether an approval process auto-starts on creation |
Layout¶
Controls the arrangement of tabs within the ticket detail view. Uses the standard system layout by default, but can be switched to a custom layout where tabs are reordered or hidden via drag-and-drop.
Field List¶
Defines which fields appear on this ticket type, including both system fields and custom fields.
| Capability | Description |
|---|---|
| Add fields | Select from available system and custom fields to include on this ticket type |
| Field visibility | Configure per field: visible to agents, visible to end users on new tickets, visible on existing ticket details, and whether the field is mandatory |
| Dynamic field visibility | Show a field only when conditions on another field are met (e.g., selecting "Hardware" in a category reveals a "Device Type" field) |
| Dynamic value visibility | Show or hide values within a dropdown based on conditions set on another field |
| Field groups | Organize related fields into reusable groups that can be shared across ticket types |
Dynamic visibility enables guided intake forms where answering one question reveals the next, making it possible to build questionnaire-style forms per ticket type.
Forms¶
Controls how the ticket creation form appears in different contexts. The agent portal and self-service portal can have different form layouts and field ordering for the same ticket type, so end users see a simplified view while agents see the full field set.
Allowed Values¶
Restricts which system-defined values (statuses, actions, priorities) are available on tickets of this type. When "Allow All" is unchecked, administrators must explicitly add each permitted value.
This allows different ticket types to have different status sequences. For example, a Change Request might progress through Submitted, Under Review, Approved, Scheduling, Implementation, Review, and Closed, while a Service Request might simply use New, In Progress, and Completed.
Settings¶
Behavioral configuration for ticket lifecycle events.
Status transitions:
- Status after end-user update (e.g., set to "Updated" when the end user responds)
- Status after agent update
- Other status-after-action rules configurable per response type
Closure behavior:
- Whether emails on closed tickets should reopen them
- Whether all child tickets must be closed before the parent can close
- Whether a closure confirmation process is required
Notification behavior:
- SLA hold reminders
- Account manager email notifications
- CC behavior for ticket followers
Child Ticket Display¶
For ticket types that use child tickets (like Projects), administrators can configure how children are displayed:
| View | Description |
|---|---|
| Table | Standard list view with configurable columns |
| Gantt | Timeline view for project planning (requires start and target dates on child tickets) |
| Kanban | Drag-and-drop board where administrators choose which statuses appear as columns |
Task dependencies can be enabled per ticket type, allowing child tickets to have dependency relationships (e.g., Task B cannot start until Task A is complete).
Access Restrictions¶
Ticket types can be restricted at multiple levels to control who can see and work with them:
| Restriction | Where Configured |
|---|---|
| Role-based restrictions | Restrict agents in a specific role to only see certain ticket types (configured under Teams & Agents > Roles) |
| Portal visibility | Control whether the ticket type appears in the end-user self-service portal (configured on the Details tab) |
| Field-level visibility | Control which fields end users can see versus what agents see (configured on the Field List tab) |
| Configuration access | Grant specific agents or roles permission to modify this ticket type's configuration (configured via the Access Control button) |
Relationship to Other Configuration¶
Ticket types connect to many other configuration areas:
| Configuration | How It Relates |
|---|---|
| Ticket Templates | Templates are associated with ticket types and pre-populate fields and child tasks on creation |
| Ticket Rules | Rules can trigger based on ticket type for auto-assignment, categorization, and notifications |
| Approval Processes | Approval processes can be auto-started per ticket type |
| Service Level Agreements | SLA policies can be defaulted per ticket type |
| Integrations > Webhooks | Webhooks can fire based on events scoped to specific ticket types |
| Categories | Categories can be defaulted or restricted per ticket type |
| Workflows | Workflows can be auto-started per ticket type and constrain available actions per step |