Using Customer Request Type in a Workflow Condition

[Michael Matthews]

Hi, 

I am trying to create different Resolved workflow transitions using based on the "Customer Request Type".  I want to make certain fields required for certain Customer Request Types. 

I am using the field value Condition. 

However, I cannot get it to show. 

Has anyone had any experience getting this to work?

[Eddie Webbinaro]

As others have pointed out, you need to use a String compare on OptionID.

Getting the customer request type keys  on cloud can be done as follows (screenshots below):

1) get issue ID (not key) by hovering over the "move","convert to subtask", or other ption from the ".." dropdown.
2) Pass this to the endpoint `/rest/servicedesk/1/servicedesk/request/<<issue-ID>>/request-types` in your browser
3) Note the *portal key* and *key* in the response
4) Combine those in form `<portalKey>/<key>` in the workflow condition

Step 1 - get issue id

Step 2 Request Type "keys"

Step 4 - set condition

[Mikey Schott]

Note for Step 2, that the data returned may be multiple validRequestTypes, and you may need to sort through that list to find the specific request type that you are looking for by comparing the "name" attribute.

[Ben Griffin]

This works perfectly. Thank you for the detailed write-up.

[Jana Martinsone]

Guys!

What could be the reason, if when hovering over the "move", "convert to subtask", or other opption from the ".." dropdown there is nothing shown in in the lower corner of the browser? Thanks!

[Erica Larson]

If you switch to the old issue view in cloud instead of the new layout, you can get the ID using the hover method described.  I have not found a way to get the issue ID in the new layout.

[Ivan Milosavljevic GET]

Hi all, 

This doesn't work for me even though I followed steps and everything was as expected, set the condition like this and then it just doesn't appear where it should.

How could I troubleshoot this?

Nevermind, it works as expected, I miscopied the ID :)

P.S. You can easily get issue ID from new issue view by selecting ... Export XML, then reading it in XML in line <key id="47542">EXAMPLE-123</key>

[Dimitar Dimitrov]

Hey I think I have a solution for you here. Prerequisite - install Scriptrunner as you will need the ScriptRunner console. Then:

1. create a ticket from the portal form (to later get the Request Type)

2. open script runner and run the following script for that issue

of course, replace INTSD-50X with the number of your issue. Leave the rest as it is above.

3. See the ID (intsd/something as in your case intsd will be replaced by the ID of your project)

4. go to the validator and select to validate by ID, enter the ID from the script runner result there to represent the Request Type which was used to create the issue in the first place

[Florian Reichl]

Cool, seems to be a workaround...

[Chrisjir Parkin]

This worked for us, too.  We were able to set a Condition based on the Jira Service Desk field "Customer Request Type" using the Value Field condition.

[Dimitar Dimitrov]

I have the same issue with JSD. Value Field Condition is supposed to work when you give it a condition of String = 'name of the request type', but it's not working.

[Gary Fitzgerald]

+1

[Bethany Amborn]

I am having the same need. I have one workflow, but different request types route slightly differently. Having a hard time making this happen...

[Florian Reichl]

me too, don't get the point in why this doesn't work as expected

[somethingblue]

Hi Michael,

Just to clarify, are you trying to get certain fields to show up on the screen based on the issue type chosen?

If that is the case you're going to need to look into an add-on such as ScriptRunner or Bob Swift CLI.

In addition, since JIRA does not change views based on selection in that manner I would also advise you create a Suggestion at JAC and post the link here so the Community can vote on it.

Cheers,

Branden

[Michael Matthews]

I am trying to have specific workflow transitions to show for specific Customer Request Types. We are using different types to handle slight differences in service desk requests. We are also using ServiceDesk Cloud so I don't think those are available to me.