# Ticket configurations This document outlines the available ticket configurations, including their specific attributes, default values, and workflow transitions. --- ## 1\. Incident An ITSM Incident is any unplanned interruption to an IT service, reduction in service quality, or failure of a configuration item that has not yet impacted a service. ### Configuration | Configuration | Value | | :--- | :--- | | **Color & Icon** | ![Icon]()   `#003964` | | **ID Strategy** | `timestampBased` | | **Activated Features** | `severity`, `description`, `timeTracking`, `taskList`, `slaMonitoring`, `documentStorage`, `inventoryIntegration`, `relations`, `emailIntegration`, `comments`, `reporter` | ### Default Values | Field | Value | | :--- | :--- | | **`workflowState`** | New (v1000) | | **`severity`** | `10` | | **`tags`** | responsible: `my-team@company.com`
classification: `Password reset` | | **`description`** | \# Incident Summary

Briefly describe the incident in one or two sentences.

\#\# What happened?

Describe the issue in detail.
\- What was observed?
\- What error messages occurred?
\- When did the issue start?

\#\# Business Impact

Describe the impact on the business.
\- Which services were affected?
\- Which users or departments were impacted?
\- What was the severity?

\#\# Investigation

Document your investigation.
\- What was checked?
\- Which logs, alerts, or monitoring systems were reviewed?
\- What findings were identified?

\#\# Root Cause

Describe the identified or suspected root cause.
If unknown, explain why it has not yet been determined.

\#\# Resolution

Describe the actions taken to restore the service.

\#\# Preventive Actions

Describe actions that should be taken to prevent this incident from happening again.

\#\# Additional Information

Include any relevant notes, references, links, or attachments. | ### Workflow transitions ``` stateDiagram-v2 v1000: New v1010: Assigned v1020: In progress v1030: Pending approval v1040: Pending feedback v1050: On hold v1060: Resolved v1070: Closed v1080: Cancelled v1090: Reopened v1000 --> v1010: Assign ticket v1000 --> v1080: Cancel ticket (Spam/Duplicate) v1010 --> v1020: Start work v1010 --> v1040: Request information v1010 --> v1000: Unassign v1010 --> v1080: Cancel ticket v1020 --> v1040: Request information v1020 --> v1050: Put on hold v1020 --> v1060: Resolve incident v1020 --> v1030: Request approval v1020 --> v1080: Cancel ticket v1030 --> v1020: Approve and resume work v1030 --> v1080: Reject and cancel v1040 --> v1020: Provide feedback / Resume work v1040 --> v1060: Resolve based on feedback v1040 --> v1080: Cancel (No response) v1050 --> v1020: Resume work v1050 --> v1080: Cancel ticket v1060 --> v1070: Confirm resolution & Close v1060 --> v1090: Reopen (Fix failed) v1070 --> v1090: Force reopen v1080 --> v1090: Force reopen v1090 --> v1010: Re-assign v1090 --> v1020: Resume work immediately ``` --- ## 2\. Problem A Problem is the unknown cause of one or more Incidents. The goal of Problem Management is to minimize the impact of incidents and prevent recurrence. ### Configuration | Configuration | Value | | :--- | :--- | | **Color & Icon** | ![Icon]()   `#5E5CE6` | | **ID Strategy** | `timestampBased` | | **Activated Features** | `severity`, `description`, `timeTracking`, `taskList`, `documentStorage`, `inventoryIntegration`, `relations`, `comments`, `reporter` | ### Default Values | Field | Value | | :--- | :--- | | **`workflowState`** | New (v1000) | | **`severity`** | `10` | | **`tags`** | category: `Software/Hardware/Network`
rca\_status: `Pending` | | **`description`** | \# Problem Summary

Describe the problem and the underlying symptoms observed across related incidents.

\#\# Related Incidents
List the IDs of known incidents related to this problem.

\#\# Root Cause Analysis (RCA)
Document the investigation steps and identified root cause.
\- What caused the failure?
\- Why did the preventive measures fail?

\#\# Workaround
Is there a temporary workaround available to restore service for affected users? Describe it here.

\#\# Permanent Fix
Describe the planned or implemented solution to permanently remove the root cause.

\#\# Action Items
List tasks required to implement the fix or improve monitoring/prevention. | ### Workflow transitions ``` stateDiagram-v2 v1000: New v1010: Assigned v1020: In progress v1040: Pending feedback v1050: On hold v1060: Resolved v1070: Closed v1080: Cancelled v1090: Reopened v1000 --> v1010: Assign Problem v1000 --> v1080: Cancel (Not a problem) v1010 --> v1020: Start RCA v1020 --> v1040: Request more data v1020 --> v1050: Put on hold (Monitoring) v1020 --> v1060: Workaround / Fix found v1040 --> v1020: Information received / Resume RCA v1050 --> v1020: Resume RCA v1050 --> v1060: Accept as known error v1060 --> v1070: Close Problem v1060 --> v1090: Reopen (Recurrence) v1070 --> v1090: Force reopen v1080 --> v1090: Force reopen v1090 --> v1010: Re-assign ``` --- ## 3\. Change Request A Change Request (CR) is a formal proposal to modify any IT service or configuration item to minimize risk and disruption. ### Configuration | Configuration | Value | | :--- | :--- | | **Color & Icon** | ![Icon]()   `#F59E0B` | | **ID Strategy** | `timestampBased` | | **Activated Features** | `severity`, `description`, `timeTracking`, `taskList`, `documentStorage`, `inventoryIntegration`, `relations`, `comments`, `reporter` | ### Default Values | Field | Value | | :--- | :--- | | **`workflowState`** | New (v1000) | | **`severity`** | `5` | | **`tags`** | change\_type: `Standard / Normal / Emergency`
cab\_required: `Yes / No` | | **`description`** | \# Change Summary

Provide a high-level summary of the proposed change.

\#\# Reason for Change
Why is this change necessary? (e.g., security patch, new feature, hardware end-of-life)

\#\# Risk Assessment & Impact
\- **Impact:** What systems or users will be affected?
\- **Downtime:** Is there any expected downtime?
\- **Risk Level:** Low / Medium / High

\#\# Implementation Plan
Step-by-step instructions on how the change will be executed.

\#\# Rollback Plan
Step-by-step instructions on how to revert the change if it fails.

\#\# Testing / Verification
How will we verify that the change was successful? | ### Workflow transitions ``` stateDiagram-v2 v1000: New v1010: Assigned v1020: In progress v1030: Pending approval v1040: Pending feedback v1050: On hold v1060: Resolved v1070: Closed v1080: Cancelled v1090: Reopened v1000 --> v1030: Submit for Approval (CAB) v1000 --> v1080: Cancel Change v1030 --> v1010: Approve & Assign v1030 --> v1040: Request Revision v1030 --> v1080: Reject Change v1010 --> v1020: Start Implementation v1010 --> v1050: Schedule for later v1020 --> v1060: Implementation Complete (Pending PIR) v1020 --> v1080: Rollback & Cancel v1040 --> v1030: Resubmit for Approval v1050 --> v1010: Ready to Implement v1060 --> v1070: Post Implementation Review (PIR) & Close v1060 --> v1090: Reopen (Issues detected) v1070 --> v1090: Force reopen v1080 --> v1090: Force reopen v1090 --> v1010: Re-assign ``` --- ## 4\. Task list A task list is a structured collection of actionable items or duties that need to be completed, typically organized by priority or deadline to help individuals track progress and manage their workflow efficiently. ### Configuration | Configuration | Value | | :--- | :--- | | **Color & Icon** | ![Icon]()   `#de03c8` | | **ID Strategy** | `timestampBased` | | **Activated Features** | `taskList` | ### Default Values | Field | Value | | :--- | :--- | | **`workflowState`** | New (v1000) | | **`severity`** | `1` | ### Workflow transitions ``` stateDiagram-v2 v1000: New v1020: In progress v1070: Closed v1000 --> v1020: Start working v1020 --> v1070: Complete tasks v1070 --> v1020: Reopen task ``` --- ## 5\. Request for Enhancement A Request for Enhancement (RFE) is a proposal to improve an existing product, service, or system by adding new features or modifying current functionality. ### Configuration | Configuration | Value | | :--- | :--- | | **Color & Icon** | ![Icon]()   `#00C7BE` | | **ID Strategy** | `timestampBased` | | **Activated Features** | `severity`, `description`, `comments`, `documentStorage`, `taskList`, `reporter` | ### Default Values | Field | Value | | :--- | :--- | | **`workflowState`** | New (v1000) | | **`severity`** | `5` | | **`tags`** | product: `SAP FI`
solution: `xyz` | | **`description`** | \# Request for Enhancement

\#\# Use Case
Describe the scenario or problem that necessitates this enhancement.

\#\# Current Behavior
How does the system currently behave? What are the limitations?

\#\# Desired Behavior
How should the system behave after this enhancement is implemented?

\#\# Value / Business Impact
What is the expected benefit? (e.g., saves time, reduces errors, improves user experience, drives new revenue)

\#\# Additional Information
Include any relevant mockups, examples, or references. | ### Workflow transitions ``` stateDiagram-v2 v1000: New v1010: Assigned v1020: In progress v1030: Pending approval v1040: Pending feedback v1050: On hold v1060: Resolved v1070: Closed v1080: Cancelled v1090: Reopened v1000 --> v1030: Request approval v1000 --> v1080: Reject enhancement (Out of scope) v1030 --> v1010: Approve and Assign v1030 --> v1050: Move to Backlog (On hold) v1030 --> v1080: Reject v1010 --> v1020: Start implementation v1010 --> v1050: Move back to Backlog v1020 --> v1040: Request clarification v1020 --> v1060: Enhancement implemented v1040 --> v1020: Clarification provided / Resume work v1050 --> v1010: Pull from Backlog and Assign v1050 --> v1080: Cancel request v1060 --> v1070: Verify and Close v1060 --> v1090: Reopen (Needs adjustment) v1070 --> v1090: Force reopen v1080 --> v1090: Force reopen v1090 --> v1010: Re-assign ``` --- ## 6\. Epic An Epic is used to logically organize, categorize, or bundle multiple related tickets together, often representing a broader initiative or an overarching theme. It has no functional impact! ### Configuration | Configuration | Value | | :--- | :--- | | **Color & Icon** | ![Icon]()   `#8D6E63` | | **ID Strategy** | `timestampBased` | | **Activated Features** | `description` | ### Default Values | Field | Value | | :--- | :--- | | **`workflowState`** | New (v1000) | | **`tags`** | scope: \`\` | | **`description`** | \# Epic Overview

Provide a brief description of the overarching goal or theme of this Epic.

\#\# Scope
\- What kind of tickets, tasks, or features belong to this Epic?
\- Are there any specific milestones, acceptance criteria, or deadlines associated with it?

\#\# Additional Notes
Include relevant documentation, links, or references for the items contained within this Epic. | ### Workflow transitions ``` stateDiagram-v2 v1000: New v1020: In progress v1070: Closed v1000 --> v1020: Start working v1020 --> v1070: Complete tasks v1070 --> v1020: Reopen task ``` --- ## 7\. Approval An Approval ticket is used to obtain formal consent, authorization, or sign-off from stakeholders for a specific action, document, or expenditure. ### Configuration | Configuration | Value | | :--- | :--- | | **Color & Icon** | ![Icon]()   `#10B981` | | **ID Strategy** | `timestampBased` | | **Activated Features** | `description`, `documentStorage`, `comments`, `reporter` | ### Default Values | Field | Value | | :--- | :--- | | **`workflowState`** | New (v1000) | | **`tags`** | approval\_type: `Financial / Technical / Access / Holiday`
department: \`\` | | **`description`** | \# Approval Request

\#\# What needs to be approved?
Provide a clear and concise description of the request (e.g., software license purchase, access rights, architectural decision).

\#\# Context & Justification
Why is this necessary? What are the benefits or costs?

\#\# References
Link any relevant tickets (e.g., Change Requests, Incidents), documents, or quotes here. | ### Workflow transitions ``` stateDiagram-v2 v1000: New v1030: Pending approval v1040: Pending feedback v1060: Resolved v1070: Closed v1080: Cancelled v1090: Reopened v1000 --> v1030: Submit for Approval v1000 --> v1080: Withdraw Request v1030 --> v1060: Approve Request v1030 --> v1040: Request Clarification v1030 --> v1080: Reject Request v1040 --> v1030: Clarification Provided v1040 --> v1080: Withdraw Request v1060 --> v1070: Close (Archived) v1070 --> v1090: Force reopen v1080 --> v1090: Force reopen v1090 --> v1030: Resubmit for Approval ``` --- ## 8\. Risk A Risk ticket is used to document, assess, and mitigate potential threats or vulnerabilities that could negatively impact projects, services, or business operations. ### Configuration | Configuration | Value | | :--- | :--- | | **Color & Icon** | ![Icon]()   `#E53935` | | **ID Strategy** | `timestampBased` | | **Activated Features** | `severity`, `description`, `taskList`, `documentStorage`, `comments` | ### Default Values | Field | Value | | :--- | :--- | | **`workflowState`** | New (v1000) | | **`severity`** | `7` | | **`tags`** | risk\_category: `Security / Operational / Financial`
status: `Identified` | | **`description`** | \# Risk Description

Clearly define the risk event and its potential causes.

\#\# Assessment
\- **Probability (1-5):**
\- **Impact (1-5):**
\- **Overall Risk Score:**

\#\# Mitigation Strategy
What actions will be taken to reduce the probability or impact of this risk?

\#\# Contingency Plan
What is the plan B if the risk actually materializes?

\#\# Current Status / Monitoring
Document the ongoing monitoring activities and any changes to the risk profile. | ### Workflow transitions ``` stateDiagram-v2 v1000: New v1010: Assigned v1020: In progress v1050: On hold v1060: Resolved v1070: Closed v1080: Cancelled v1090: Reopened v1000 --> v1010: Acknowledge & Assign Risk v1000 --> v1080: Discard (Not a valid risk) v1010 --> v1020: Start Mitigation Work v1010 --> v1050: Accept Risk & Monitor v1020 --> v1050: Mitigation Applied / Switch to Monitoring v1020 --> v1060: Risk Eliminated v1050 --> v1020: Risk Escalated / Resume Mitigation v1050 --> v1060: Risk Retired (No longer relevant) v1060 --> v1070: Close Risk Record v1060 --> v1090: Reopen (Risk resurfaced) v1070 --> v1090: Force reopen v1080 --> v1090: Force reopen v1090 --> v1010: Re-assign ```