Is it possible to clone request types?

[Juan Ignacio Tel]

Hi there,

We are starting with JSM and would like to create several request types with small differences on their configuration between them, so it would definitely be useful if we could clone them.

Is there any way to achieve it without having to re-create them from scratch?

Any help will be appreciated.

Thanks in advance.

[Connor · Accepted solution]

Yes it's possible, go to Project settings --> Request types --> click options button beside the request type --> click Duplicate --> follow the remaining prompts. That will create a new request type with identical settings to the original. 

[Juan Ignacio Tel]

Thanks for your indication Connor.

Maybe I'm totally missing it, and of course we're newbies, but I think I already tried that (as most logical way to find the option).

When I click on the ellipsis button, the only available option is "Delete request type".

I'm admin so and I can fully edit or delete the request type.

I saw this article Duplicate request type available in Jira Service M... - Atlassian Community but, in the same way as one person comments that is not seeing the duplicate option, neither I am.

P.D. Sorry, I forgot to mention that we're using JSM on Cloud, using IT Service Management (Essentials) template, team-managed project, just in case that's relevant.

[Connor]

Yeah it looks like this is only for company-managed projects. The user commenting on the article you linked states:

I cannot see the list as in the screenshot here, When I open the Request Types section. screen goes directly on the first one.

I've tested on a team-managed project (TMP) and I see the same behavior. There are no request type categories in a TMP, so you're taken straight into the configuration of the first request type in your list. Just another of the many reasons to not use TMPs.

[Juan Ignacio Tel]

Thanks for your testing Connor. That clears up the matter.

I fear that we don't have too many resources on our org, and TMPs have allowed us to start our JSM journey in a more friendly way.

You've kind of frightened me: I'm pretty sure that TMPs are not the pro-way of dealing with JSM, but reading your answer it looks like there are a lot of reasons to be away from them.

Any specific advice knowing that we're around 100 users ("clients") and no more than 4 agents?

[Connor]

We also started our use of JSM (was JSD when we started using it) using a TMP when we were only ~15 users and 2 agents. At first the TMP was really convenient as it could be setup very fast. Soon we ran into issues with CMP functionality missing in the TMP and marketplace app compatibility problems. When we started to expand we realized the benefit of the easier setup/management being contained to each TMP is lost to us because our user team leads don't want to add "Jira project admin" duties to their workloads. Which left all of that work with us the Jira admins, and at that point it made more sense to switch to CMPs so we could at least benefit from shared workflows/issue types/etc. across projects. 

It makes even more sense to use CMPs for JSM projects due to Atlassian's investments into and integration of Insight asset mgmt, Opsgenie alerts/incidents, Jira automation, forms, and more into the ITSM template.

Overall it really feels like TMPs are an afterthought for Atlassian. I understand their desire to reduce the admin overhead generally associated with CMPs but I they've really missed the mark.