/ /
The Ticket Immutability snap-in enables automatic enforcement of immutability on closed tickets. Organizations use this snap-in to maintain compliance with data governance policies, prevent accidental edits on resolved tickets, and preserve audit integrity.
Once activated, tickets are marked as immutable after a defined number of days in a closed state, excluding those in the Accepted stage. After this period, no further modifications are permitted. This includes restrictions on rich-text editor access, field updates, object linking, and other changes, ensuring ticket integrity.
This snap-in requires workspace admin privileges to install and configure.
Behavior
Immutability enforcement
Once immutable, agents and customers cannot modify any fields, link objects, or edit the ticket's content. Immutable tickets display a read-only indicator in the ticket view; fields are not editable and the rich-text editor is disabled.
Agents and admins can confirm that a ticket has been marked immutable by opening the ticket and observing that all fields are in read-only mode and the rich-text editor is disabled. The ticket's stage and field values remain visible but cannot be changed. Admins can also filter or search tickets by immutability-related attributes in the workspace to audit which tickets have been frozen.
Immutability application
When a ticket has remained in a closed state (other than Accepted) for the configured number of days, the snap-in marks it as immutable.
📝 Note: To apply immutability to tickets, this snap-in runs about once per hour. On each run it can mark up to 50 tickets immutable. If there are a lot of tickets that meet the criteria for immutability, it can take multiple cycles to mark them all.
Follow-up ticket creation
When a customer responds to an immutable ticket, the snap-in automatically creates a follow-up ticket, ensuring that customer inquiries are never lost while preserving the integrity of the original closed ticket.
For follow-up ticket creation to work correctly, at least one stage on the ticket object must be configured as a terminal stage. None of the default stages are terminal, so this must be set up explicitly before relying on this behavior. If a customer responds a second time to the same ticket that is already in a terminal stage, no additional follow-up ticket is created — the message is added to the existing follow-up ticket instead.
Automatic archiving
Tickets are automatically archived 180 days after becoming immutable.
AirSync ticket exemption
Tickets imported through AirSync are exempt from being set as immutable. This prevents conflicts with synchronization workflows that may need to update ticket data after import.
Installation
Go to Settings > Snap-ins and click Explore Marketplace in the top-right corner.
In the DevRev Marketplace, find Ticket Immutability and click Install.
In the Configuration Settings, specify the number of days after which a closed ticket becomes immutable, then click Save.
Click Install to activate the snap-in.
(Optional) In the Configuration Settings, specify the number of days (1–365) after which a closed ticket becomes immutable. The default value is 365 days. A ticket must remain in a closed state (excluding Accepted) for this entire period before immutability is enforced.
Was this article helpful?