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	`#003964`
ID Strategy	`timestampBased`
Activated Features	`severity`, `description`, `timeTracking`, `taskList`, `slaMonitoring`, `documentStorage`, `inventoryIntegration`, `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	`#5E5CE6`
ID Strategy	`timestampBased`
Activated Features	`severity`, `description`, `timeTracking`, `taskList`, `documentStorage`, `inventoryIntegration`, `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	`#F59E0B`
ID Strategy	`timestampBased`
Activated Features	`severity`, `description`, `timeTracking`, `taskList`, `documentStorage`, `inventoryIntegration`, `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	`#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	`#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¶

A 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	`#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	`#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	`#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