Type Reclassification Flows(3.4.9)

When an issue's type is changed after it was created, it means the initial categorization was wrong. Sometimes this is routine — a Task that turned out to be a Bug. But a consistent pattern of reclassifications from one type to another can reveal a gap in how your team categorizes work at intake, or, if the direction is always away from Incident, a pattern worth asking about.

This view provides the trail of how issues moved between types, and when, which is what a NIS2 reviewer would follow.

What you can conclude

• A high volume of reclassifications from Task to Bug suggests that bugs are being underreported at creation — the team is categorizing them as tasks to avoid escalation.
• Reclassifications that consistently happen in the same direction may indicate a categorization training gap.
• A low reclassification count overall is a positive signal — the team is categorizing work correctly at intake.

How this chart works

Flow chart showing reclassification events between issue types, with source and destination type, count of events, and timing. Use the project and date filters to focus on specific teams or periods.

Two kinds of type change are deliberately not drawn. A change between two issue types that share the same display name is a move between issue type schemes rather than a categorization being corrected, and drawing it would put a same-name loop on the chart. A change involving a type whose name has never been observed for your site is also left out, because it cannot be placed on the chart without inventing a label for it.