Tickets

ticketing system detailed core components documentation this document provides an in depth technical specification for the ticketing system's core components it outlines how the system automatically calculates priority, handles major incidents, supports px (priority exception) tickets, and manages ticket followers the focus is on system behavior, data model, and automation triggers priority (impact & urgency) overview tickets are assigned a priority level (p level) based on two key attributes urgency reflects how quickly the ticket requires a response impact indicates the severity of the issue on operations or users the system automatically computes the p level from these values, which drives sla timings, notifications, and escalation procedures authorized users have the ability to override the computed p level when necessary data fields urgency type enum options high , medium , low , n/a description represents the time sensitivity of the ticket for tickets not governed by sla, "n/a" may be selected impact type enum options high , medium , low , n/a description represents the extent of disruption caused by the ticket "n/a" is used where impact is not applicable p level (priority) type derived value (e g , p1 , p2 , p3 , p4 ) description automatically calculated using the matrix below priority calculation matrix the matrix now includes a column and row for n/a if both urgency and impact are set to n/a , the ticket is treated as a px ticket and processed via a dedicated workflow (i e , it is not tracked by standard sla timers) if only one of the fields is n/a , the priority is calculated based on the provided value impact \ urgency high medium low n/a high p1 – critical p1 – critical p2 – high p2 – high medium p1 – critical p2 – high p3 – moderate p3 – moderate low p2 – high p3 – moderate p4 – low p4 – low n/a p2 – high p3 – moderate p4 – low px note when only one field (urgency or impact) is n/a , the priority is derived solely from the provided value using the corresponding mapping in the table when both fields are n/a , the ticket is classified as a px (priority exception) ticket, meaning it bypasses standard sla tracking and follows a dedicated workflow px (priority exception) tickets overview px tickets are a special category where standard urgency and impact measures do not apply for px tickets field values both urgency and impact are set to n/a p level calculation although a p level is computed (displayed as px), these tickets bypass standard sla tracking and escalation processes workflow px tickets excludes them from sla timers they are recorded for audit and reporting purposes, but they are not counted in sla performance metrics use cases typical use cases include informational requests, non critical internal communications, or tickets where sla tracking is not relevant major incidents major incident identification major incident toggle type boolean description a flag on the ticket indicating that it is a major incident this flag can be set manually by authorized users or automatically based on conditions such as the ticket's p level combined with additional criteria automated behavior on major incident activation when a ticket is marked as a major incident distribution list retrieval the system automatically retrieves a pre defined major incident stakeholders distribution list from configuration settings this list contains user ids and/or email addresses of key stakeholders automatic follower addition all members from the distribution list are added as followers of the ticket their follow entries are marked with the reason "auto follow major incident distribution " enhanced notification workflow the system triggers enhanced notifications across multiple channels (email, sms, in app) the ticket is visibly marked with a "major incident" badge in the user interface, and stakeholders receive immediate alerts audit and logging all changes to the major incident toggle state are logged for audit purposes, ensuring traceability and accountability ticketfollowers table purpose the ticketfollowers table tracks users who follow a ticket to receive notifications about updates it supports both manual follows (user opt in) and automatic follows (e g , for major incidents) table schema column name data type constraints description follower id uuid/int primary key, not null unique identifier for each follow entry ticket id uuid/int foreign key, not null identifier linking to the associated ticket references the tickets table user id uuid/int foreign key, not null identifier of the user following the ticket references the users table reason varchar/text not null, default "user opt in" describes why the user is following the ticket (e g , "user opt in" or "auto follow major incident distribution") created at timestamp not null, default current timestamp timestamp when the follow entry was created updated at timestamp nullable timestamp when the follow entry was last updated usage scenarios manual follow a user chooses to follow a ticket by clicking the "follow" link or button a record is created in the ticketfollowers table with the reason set to "user opt in " automatic follow for major incidents when a ticket's major incident toggle is activated, the system automatically adds all stakeholders from the distribution list as followers their records are added with the reason "auto follow major incident distribution " integration with the notification system notification dispatch the notification engine queries the ticketfollowers table to compile a list of recipients for ticket updates both manual and automatic followers receive notifications according to their preferred channels (email, sms, in app) synchronization any update to a ticket (such as a status change or comment) triggers a refresh of the follower list to ensure that all current followers are notified developer implementation checklist priority and automation define urgency and impact fields as enums with options high , medium , low , n/a implement backend functionality to calculate the p level using the updated matrix, including handling cases where one field is n/a allow for manual override of the calculated p level by authorized users integrate sla timers and escalation logic based on the computed p level px ticket handling introduce a ticket type or flag for px (priority exception) tickets enforce that for px tickets, both urgency and impact are set to n/a route px tickets through a dedicated workflow that excludes them from sla tracking and escalation processes ensure px tickets are recorded for audit and reporting purposes major incident handling add a boolean major incident toggle to the ticket data model configure a major incident distribution list in the system settings implement logic to automatically add followers to tickets marked as major incidents trigger enhanced notifications and update ui elements when a ticket is flagged as a major incident log all changes to the major incident status for audit purposes ticketfollowers table create the ticketfollowers table with the specified schema implement logic for manual ticket following, recording user opt in automatic addition of stakeholders when a ticket is marked as a major incident ensure the notification system queries the ticketfollowers table to dispatch updates develop and run tests for both manual and automatic follow functionalities this detailed documentation provides a comprehensive guide for developers to implement the core features of the ticketing system, including automated priority calculation (with px considerations), robust major incident management, and efficient tracking of ticket followers