Lookup Tables?

[Mary Mascari]

OK, here's what I want to do:

I want to be able to present users with user-friendly options to categorize their requests, and then have them map to our own Components field.

I'm thinking the way to do this would be a table of some sort:

Request Type	User Friendly Label	Component
Request Access to a Resource	Add to Mailbox or Distribution List	Outlook and Email
Request Access to a Resource	Teams group or SharePoint Site	Teams, SharePoint, OneDrive
Request Access to a Resource	SAP Role or Transaction	SAP

and so on, with more rows for different Request Types, too.

This table could live pretty much anywhere. I've got SharePoint handy, but I'm flexible there.

On the request form:

We'd have a custom drop-down that shows the User Friendly Label values for the particular Request Type.

When they choose a User Friendly Label value, it would also populate the Components field with the corresponding value from the Component column.

I don't want to have to write a huge switch statement (or--horrors--nested Ifs) to do the lookups.

I assume this isn't natively possible, but is there a good add-in that might do this? 

Thanks in advance!

[Mike Rathwell]

Hi @Mary Mascari 

I feel like you are making this harder on yourself than it needs to be. Curiously, your mention of SharePoint being available suggests why this might be the case. There isn't an easy way to do anything in SharePoint.

If it was me doing it, I can see a couple of ways of going about it to give the stated aim of an easy way for users to categorize their requests AND set your component.

The first way:

• Set up a unique request type for each of the different... request types. They appear as discrete entries on the portal and you have the added advantage of being able to add request specific icons to each for clarity and also make the portal look nicer
• Add components as a hidden field on each request type. This means you need to set a value to have it hidden BUT if each request type is unique, you can set the unique component there.

The second way:

• Set up a single request type for all of them
• Create a custom dropdown field for the different categories of that request
• Use Jira Automation to set component based on the value in the drop down after create

A note.... if you take the first (and easiest way both for you and your users), unless you use components elsewhere in the system, you really don't need it. The request type IS the component in question and you can report on that as easily as by component.

A bonus to the first way; you can have request specific forms/fields for each of them. You don't need a giant form with all possibilities; just the fields relevant for that kind of a request. It is also easier to set some required based on the request type.

Also... the first way... if one selects the "wrong" request type, the OTHERS then appear as a dropdown at the top of the form to be able to select another.

Hope this helps

[Kai Sören Becker]

Hi @Mary Mascari

I'm on @Mike Rathwell side with this. Usually it is a good option to stick to the standard features. 
But, if you are still willing to pull the info for the fields from external sources, you could probably try Elements Connect 
It allows you to create custom dropdowns with external data. But be aware, that you probably should take care on error handling, like communication breakdown between field and source, or changes in the datasource, that might break previous selections in issues.

If you are using JSM Cloud premium, you could also consider to use Insight for the dropdowns.

For both ways, you will still need an automation rule so map the info to your component fields.