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.
- 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.
- 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.
- 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"?
- 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.
