Clarification on JSM plan changes – impact on our Change request types / work categories (Standard)

[bartlomiej_siwek]

Hello there,

I’ve read your disclaimer about moving Advanced Incident, Change, and Problem management capabilities to Premium/Enterprise, but a few points are still unclear for our setup.
Context: We do not use Change queues, Change calendar, risk assessments, Post-incident Reviews, or Problems. We only use our own queues and “Change” as part of our everyday process.

Could you please confirm the following for a Jira Service Management Standard site:

1. Request type visibility

   • Will our request type(s) related to Change disappear from the portal or project after the change, or will they remain available (just without the “Change” work category features)?

2. Work category / work type

   • We don’t have a strict “Change” module enabled; instead we use a work type / work category = “Change Request” (and/or a custom issue type).

   • Will this work category = Change Request be removed or unset on existing issues?

   • If removed, what will replace it on existing items? Will they simply show as “Unassigned” in Project settings → Request types, or mapped to another category?

3. Fallback mapping

   • If a change-related request type/work category is removed, what request type/work category do issues fall back to (if any)?

   • Will the request type itself remain selectable for creating new tickets (even if listed under Unassigned)?

4. JQL guidance

   • Your recommended JQL

     "ticket category" IN (Changes, Problems) ORDER BY created DESC

     returns a significant number of items on our instance. Does this mean those items will lose their “ticket category” value (i.e., the field will be cleared or become unavailable) after the change? If not, how will this field behave on existing issues?

5. Automations

   • We rely on automation rules that (a) create issues with issue type = CR (our custom “Change Request”), and (b) trigger conditions like work category = Change Request.

   • Will these automations continue to run after the change? If the work category becomes unavailable, what precise field/value should we switch to in our automation conditions (e.g., request type, issue type, labels)?

Any official, definitive mapping/behavior you can share (including whether there is a grace period per tenant/renewal date) would help us prevent broken queues and rules.

Thanks in advance!

Best regards,

Bartlomiej

[Marc - Devoteam]

Hi @bartlomiej_siwek 

Welcome to the community.

1. Request type visibility
   • Will our request type(s) related to Change disappear from the portal or project after the change, or will they remain available (just without the “Change” work category features)?
     
     No, just the Change work category features will be removed
2. Work category / work type
   • We don’t have a strict “Change” module enabled; instead we use a work type / work category = “Change Request” (and/or a custom issue type).
   • Will this work category = Change Request be removed or unset on existing issues?
     
     No, this will remain
   • If removed, what will replace it on existing items? Will they simply show as “Unassigned” in Project settings → Request types, or mapped to another category?
     
     They will be under Request Types or mapped to Unassigned if you use other features like Service Management
3. Fallback mapping
   • If a change-related request type/work category is removed, what request type/work category do issues fall back to (if any)?
     
     See above
   • Will the request type itself remain selectable for creating new tickets (even if listed under Unassigned)?
     
     Yes
4. JQL guidance
   • Your recommended JQL
     "ticket category" IN (Changes, Problems) ORDER BY created DESC
     
     returns a significant number of items on our instance. Does this mean those items will lose their “ticket category” value (i.e., the field will be cleared or become unavailable) after the change? If not, how will this field behave on existing issues?
     
     Yes, you will need to change the JQL that use Ticket category, related to change or problem
5. Automations
   • We rely on automation rules that (a) create issues with issue type = CR (our custom “Change Request”), and (b) trigger conditions like work category = Change Request.
     
     You will need to change the JQL queries or trigger that use work category
   • Will these automations continue to run after the change? If the work category becomes unavailable, what precise field/value should we switch to in our automation conditions (e.g., request type, issue type, labels)?
     
     The rule will run, but new created changes based on the work type CR and/or related request type will not be impacted, as they will not adhere to that category anymore.

I hope I provided you with enough, for you to prepare on the upcoming change.