Resolution Related to Change Enablement

[Frank Fortuna]

Our organization is going to be moving internal (ONLY) ticketing for all ITIL/ITSM related issues (Incident, Problem and Change) from JIRA to JSM.  The resolution field is a common field out of th box in both JIRA and JSM, this issue and related questions are related to Change Enablement only.

1. In my experience using other tools It is not typical for a Change (RFC) to be resolved.  A more common conclusion of a Change is its completion.

2. Once a Change has been completed there are related codes to its successful or unsuccessful implementation.  E.g., Backed Out, Successful, etc. these same examples are common KPI's for reporting on Change.

The following are questions about JSM fields, their flexibility, availability, and potential customizations related to their existing partner fields in JIRA.

1. Is it possible to create a Change form that does not include or hides the "Resolution" field completely?

         1.2 If not is it possible to customize the "Resolution” field name in JSM, so as not to affect the "Resolution" field in JIRA by calling it a different name such as "Completed"?

2. If it is not possible to do either of those to actions is it possible to create a custom field called "Completed" and a corresponding list of selections based on how a change implementation was completed?  E.g., Successful, Unsuccessful, etc.

     2.1 And if it is not possible to remove or change the "Resolution" filed name is it possible to customize the resolution reasons by eliminating out of the box responses and adding a list of custom only responses to resolution reasons, WITHOUT impacting resolution reason used by JIRA not JSM?

My concern is if shared fields such as "Resolution” are available in both JIRA and JSM, selection lists for very different activities become very large and can cause confusion offering selections of reasons related to either Dev or ITSM when comingled.

[Joseph Chung Yin]

@Frank Fortuna -

Hi Frank:

Welcome to the community.  The "Resolution" field (as you already mentioned and know) is a key element for both Jira/JSM applications at the system level (not by application).  I believe the best approach of handling your asks is by adding new resolution options for the resolution field.

Afterward, you will need to modify the WFs used by your Jira/JSM projects to restrict what resolution options to be shown when one moves the issues (either in Jira/JSM) to the terminal status.

In the WF's transition for the terminal status (i.e. "Complete" in my example see screenshot below), we excluded the resolutions options that we don't wanted to be listed in the Resolution field using "jira.field.resolution.exclude".  You can also use "jira.field.resolution.include" too to only include the options that are suitable for you.

Note - You will need to find the actual resolution option's internal IDs for this implementation.  Here is a REST API call that you can use to obtain all the resolution options IDs -

https://<yourcompany>.atlassian.net/rest/api/3/resolution

Hope this helps.

Best, Joseph Chung Yin

Jira/JSM Functional Lead, Global Technology Applications Team

Viasat Inc.