Looking for a clean way to transfer JSM issues to the correct request type (without canceling the or

[Orkhan Hasanov]

Hi everyone,

In Jira Service Management (JSM), when a request is submitted with the wrong request type, changing it isn't straightforward. First, you have to change the issue type, then assign a new request type that is mapped to that issue type. This is very difficult for agents.

In our case, each issue type has a different workflow, and which request type is linked to which issue type is not known by agents — no one can memorize all of them.

Yes, I know there’s a workaround: you can create a "Wrong Request" status and close those requests. I’ve done that in previous experience.
However, in our organization — which is completely new to JSM — we expect many mistakes during the initial months. We don't want to start by saying "you chose the wrong request" and immediately cancel users’ requests. At least for the first 6 months to 1 year, we want to be flexible, let users get used to JSM, and help them.

That’s why I’ve explored multiple solutions — but none are ideal. I’m sharing them here in case someone has a better approach.

Idea 1: Using Automation Rules
I created a custom single select field that lists all request types.
When an agent sees the request is incorrect, they choose the correct request type from that list.
The rule:

Clones the issue

Sets the correct issue type + request type

Links the old issue

Closes the old issue with a “Wrong Request” status

It works… unless the new request type requires approvals (e.g., manager approval).
If the original request type didn’t require an approver, we don't have that information.
We don’t use Guard or Assets, so the agent doesn’t know who the approver is — and it takes time to find that out. So it’s not practical for approval-based flows.

Idea 2: Using ScriptRunner
We do have ScriptRunner installed.
I haven’t used it before, so I asked ChatGPT to help.
It gave me a script, and yes — the logic is more or less the same as Automation Rule.
So, in terms of handling approval-based workflows, it didn’t really solve the core issue either.

Idea 3: Partial Manual Flow
Same as idea 1 — I created a single select field with all request types.

When an agent sees that the request is incorrect, they select the correct request type in that field.

An automation rule notifies me, and I manually review the issue and change the correct one myself.

Yes, it creates some extra work for me — but it’s currently the safest and most accurate way.
At least I have list which request types require which workflows and approvals.
Agents don’t have to figure that out.

If I don’t find anything better, I’ll probably go with Idea 3 — because agents shouldn’t be responsible for understanding the full mapping of request types and workflows.

I know this was a long post 🙂
But I’m really hoping someone here has faced the same challenge and may suggest an alternative I haven’t considered.

P.S. It’s a bit frustrating and disappointing that JSM still doesn’t offer a simple and safe way to just change the request type.

Thanks!

[Walter Buggenhout]

Hi @Orkhan Hasanov,

It looks as if a lot of the complexity comes from that you may have set up (too?) many work types to start with. That is not immediately clear from your question, but if you only use e.g. incident / change / service request and add your different request types on top of those, the number of times you'll have to update the work type along with the request type should not be that frequent. Not saying it won't happen at all, but not by the dozens, I would expect.

From that point onwards, updating just the request type across e.g. different types of incidents should be a lot less cumbersome.

Hope this helps! 

[Orkhan Hasanov]

Hi @Walter Buggenhout 

Yes, you're absolutely right. I'm already aware that we started with too many issue types but honestly, I had no other choice.

Some request types require approval from IT Security, others from the direct manager, others from the ERP team. Some requests go first to the direct manager, then to IT Security, and finally to the ERP team. Some go to optional approval, and some do not require any approval at all, etc. and so on... Because of these different approval flows, I had to separate them across multiple issue types.

Thank you very much for your feedback and suggestion — I really appreciate it.
I was aware of this approach, but due to our setup, I didn’t consider it as a viable option for us.

Thanks again!

[Marc - Devoteam]

Hi @Orkhan Hasanov 

Best practice I can give you is, train your customer base, provide them with information on what is changing.

Extra options to be done are:

- Place informational text on each Request Type, this as explanatory or help text.

- Also do this on field level in a request if necessary.

Guide your customer to the right request, you could even start using the Virtual Support Agent.

[Orkhan Hasanov]

@Marc - Devoteam Thank you !
I really appreciate your response. I’m currently working on the ideas you suggested, especially around improving descriptions and guiding users to the correct request types.

[Calvin]

Personally we do similar to what Walter noted:

• Service Request
• Incident
• Change Request

Because on a larger perspective thats what all of our tickets really are. Its within them that they split apart via request type.

It sounds like you are using unqiue types so that you have unique workflows for each? Or is there another reason you have multiple instead of having them align to just a few? Is there no way you can merge those workflows together?

Taking your example above, we have a Service Request, which includes a "approval flow" and a "dual approval flow". Depending on the Request Type chosen we have a single automation that updates a field on "who the approvers are" and "Whether it needs single, dual, no approval".

This way we have a single workflow for Service requests, but it is useable for all approval types.

[Orkhan Hasanov]

@Calvin 

Thank you for your response — I really appreciate the suggestion.

I understand your approach and yes, it makes total sense.

In my case, I hadn’t thought of merging the workflows — mainly because they were genuinely different in structure and logic. Maybe it could’ve been possible to unify some of them, but at the time, my knowledge and experience weren’t enough to do so, so we ended up splitting them by issue type.

Your idea definitely makes me rethink the overall setup.

For now, we’re avoiding closing requests as "Wrong Request" because the company just started using JSM, and we don’t want to frustrate users.

But once they’re more used to the system, we’ll move to a cleaner model using Wrong Request status + Resolution screen + Comment.

Until then, I’m exploring flexible alternatives like the one I posted.

Thanks again for your feedback!

[Calvin]

Thanks @Orkhan Hasanov I totally understand as it tripped us up when we started also. Personally I'm leaning to your first option but a bit of a difference instead of cloning an issue why not get your automation to just change the Issue (Work Item) Type and Request Type for you?

We have a similar issue with email, they all come through as an "Incident", but sometimes they actually are a Service Request. We deal with this in two ways:

1. The agent can manually change it themself by clicking on the three dots and clicking "Move" and just picking the right items. OR:
2. Very similar to your first option, when the agent sees the ticket is in the wrong area, they manually run the Automation and pick out the Request Type it should be (You can however use your list you talked about). The automation transistions it to a special "Automation only" status which is shared between all our Issue Types. This allows the automation to convert the Issue Type to another and Add the new Request Type. That way you keep the same ticket but update the values.

[Orkhan Hasanov]

Thanks @Calvin .

Yes, initially I was also inclined to use an Automation rule. I even created and tested it in our sandbox environment.

Here’s how I built it:

I created a custom single-select field with all our Request Type names.

When an agent notices the ticket has the wrong request type, they click a “Wrong Request” transition, which brings up a screen with this custom field.

Based on the selection, the automation checks the chosen value and updates both the Issue Type and Request Type accordingly.

This setup worked fine. However, I ran into a few complications:

We have many Issue Types (each with different workflows), so the rule required a lot of conditions and separate branches.

More critically, some workflows involve approval steps (e.g., Manager, ERP, IT Security, or Department Head). If a ticket originally came in via a non-approval flow and is then transitioned into an approval-required Issue Type through automation, the system expects approvers to already be set.

But since we currently don’t use Jira Guard (and may or may not implement it — discussions are ongoing), no approver fields were filled in on the original request. As a result, the issue gets stuck at the approval status with empty approver fields.

Agents often don’t know who the correct approver is (especially direct managers), so this ends up causing delays and confusion.

Because of that, I leaned toward my third idea: allow agents to mark the issue using that custom field, and I manually change the type for now — at least for the first few months until our users get used to the system.

So, to be honest, the automation idea works technically, but in practice, the approval flow created more problems than it solved in our current setup.

[Calvin]

Ah wow that is a difficult situation, you can set up a automation to add the approvers too based on the new details. But I understand that at some point Option 3 just becomes easier as there may be some flow that still gets missed. Option 3 might be a good way to see if this ends up being a big or a small problem, if you find the issue reduces a lot after a month or two in as users get used to the system then it might not be too bad.

Best of luck my friend.

[Orkhan Hasanov]

At my previous workplace, we did something very similar. Since there were only 3 issue types, it was easier for agents to manually change them, and they knew which request type belonged to which issue type.
After 6 months, we introduced a "Wrong Request" status and started closing incorrect requests using that.
I believe 6 months is a sufficient time for users to get used to the system.

Thank you for your valuable insight! @Calvin