Tickets (ITSM)

    Incidents, problems, and change requests in one place

    Overview

    Anzen's ITSM module provides three ticket types - incidents, problems, and change requests - all sharing a unified structure. This means common information, comments, and linked resources work identically across all three types, while each type has its own status workflow.

    What Every Ticket Includes

    Regardless of type, every ticket captures:

    • Ticket number - an auto-generated, human-readable identifier (see below).
    • Type - incident, problem, or change.
    • Title - a short summary of the ticket.
    • Description - a detailed explanation of the issue or request.
    • Status - the current workflow state (varies by type, see below).
    • Priority - critical, high, medium, or low.
    • Impact - the scope of effect: critical, high, medium, or low.
    • Urgency - the time sensitivity: critical, high, medium, or low.
    • Reporter - the user who created the ticket.
    • Assignee - the user responsible for working the ticket.
    • Owning entity - the entity this ticket belongs to.

    Ticket Numbers

    Every ticket receives an auto-generated, human-readable ticket number based on its type and the current year:

    • Incidents: INC2026000001, INC2026000002, ...
    • Problems: PRB2026000001, PRB2026000002, ...
    • Changes: CHG2026000001, CHG2026000002, ...

    Ticket numbers are sequential within each type and year, making them easy to reference in conversations and reports.

    Linked Resources

    Tickets can be linked to:

    • Configuration items - the assets affected by or related to the ticket.
    • Business processes - the business processes impacted by the ticket.

    These links are set when creating or updating a ticket, helping teams understand the scope and impact of each item.

    Business Impact Analysis

    Each ticket detail page has a dedicated Business Impact tab next to the Overview tab. Anzen resolves impacted business processes, process steps, and applications by traversing the ticket’s linked configuration items and direct business process associations. The tab badge shows the count of impacted processes and applications at a glance.

    The impact panel shows:

    • Impacted business processes - with financial value (if the user has the RiskValueInsight:read permission).
    • Impacted process steps - specific steps within a process that are affected.
    • Impacted applications - with criticality level, RPO, and RTO (RPO/RTO visible with RiskValueInsight:read).
    • Total financial exposure - the sum of all impacted business process values (requires RiskValueInsight:read).

    Comments

    Each ticket has a comment timeline. Comments can be:

    • User comments - added manually by team members or the reporter.
    • System comments - generated automatically when the ticket is created, its status changes, or other significant events occur.

    File Attachments

    Files can be attached to any ticket or issue to provide supporting evidence, screenshots, or documentation. Attachments are also supported on control tests.

    • Maximum file size: 50 MB per file.
    • All attachments count towards the workspace’s storage quota (1 GB on Essential, 10 GB on Professional, custom sizing on Enterprise).
    • Uploads and deletions are logged in the ticket’s activity timeline as system comments.
    • In the Service Portal, end-users can upload attachments to their own tickets and delete their own uploads. Attachments uploaded by service desk staff cannot be deleted by portal users.

    Allowed file types:

    • Images - JPEG, PNG, GIF, TIFF, WebP
    • Video - MP4, MOV, MKV, WMV, AVI
    • Documents - PDF, Word (.doc/.docx), Excel (.xls/.xlsx), PowerPoint (.ppt/.pptx)
    • OpenDocument - ODT, ODS, ODP, ODF
    • Text - Plain text, CSV

    All uploads are validated by inspecting the file’s magic bytes (binary signature), not just the file extension. This prevents uploading executables or scripts disguised as documents.

    Status Workflows by Type

    Each ticket type follows its own default status progression. See the dedicated pages for details:

    • Incidents - from New through Acknowledged and Investigating to Resolved, then Closed.
    • Problems - from New through Investigating and Root Cause Found to Resolved, then Closed.
    • Change Requests - from Draft through Submitted and Approved to Implementing, then Completed (or Rejected).

    On the Professional and Enterprise plans, administrators can define custom workflows per ticket type via Administration → Workflows. Custom workflows allow you to add, remove, or rename statuses, configure which transitions are allowed, set status colors, and define auto-assignment rules. When a custom workflow is configured, it fully replaces the default status flow for that ticket type. Deleting the custom workflow restores the defaults.

    Auto-Assignment

    Workflows support automatic ticket assignment at two levels: on ticket creation (assign to a group) and on status transition (reassign to a different group when entering a specific status). In both cases, Anzen uses a least-loaded strategy: it counts each group member’s open tickets (not yet closed, not deleted) and assigns the new ticket to the member with the fewest. Ties are broken by group membership order. All members of the assignment group receive an email notification when a ticket is routed to their queue, in their preferred language (English or Dutch).