Mapping Fields in the Request Form

[恩田翔]

Sorry if it is difficult to understand as it is written by a Japanese with machine translation.

I want to place one item for the customer to select on the request form and use another value mapped to the selected value on the automation flow.

For example, the use case is to use what is colloquially recognized in the OS host name as an option, and use the actual name that is configured in the automation flow.

In doing this, I was wondering if it would be possible to use mapping when importing CSV into a custom field. However, in reality, the automated flow did not allow smart values to reference items that were not defined in the request form.

What do you guys do when reducing the number of choices and successfully using the required values behind the scenes to improve customer usability?

[John Funk · Accepted solution]

Hi @恩田翔 

You are saying two different things. One is the CSV and the other is automation based on a form. 

What is your exact scenario that you are trying to solve? Step-by- step. 

[恩田翔]

Hi @John Funk 

Thanks for the reply.I'm sorry it's so hard to understand.

Here is a bulleted list of what I am trying to implement.

1. Create a form where the automated flow is executed as soon as an issue is submitted.
2. Place host name options in the form above.
*Host name is an abbreviation.
3. In the automation flow that is tied to the form, use smart value to get the abbreviated host name.
4. In the automation flow, we want to convert the abbreviated host name to the official host name and continue the process.

I was aware that if I mapped the context to a custom field when importing the context, it would be converted, but this is not working.

[John Funk]

Okay, you should be able to do that. 

Create you rule based on an Issue Created trigger - like you probably already have. 

Then do a services of IF/ELSE conditions with an Edit Issue under each one that updates the value to the correct one in the correct field. 

Or you could venture down creating a lookup table that has all of your options in it, but that's a little more advanced if you have not done those. 

[恩田翔]

I see. You have given me some direction, thanks.

Since there are more than 70 options, we do not think it is practical to implement this with IF/ELSE branching.

Therefore, it would be better to use a lookup table, but as mentioned above, it is difficult to manually set up more than 70 choices.

Is there an import function or something similar implemented?
In the past, there was evidence of requests for such a feature.

[John Funk]

Do all 70 have nicknames that are used and not the actual name? That's probably your problem then - and you need to use some education to teach the users the correct name to select. 

[恩田翔]

Thanks for the reply.
What you say is correct.
but I feel that perhaps cultural differences complicate it.

Since Japanese names conflict with character codes and multi-byte characters, it is common to set host names with English names separately.
However, it is difficult for newcomers to identify English names out of the blue, so I was thinking of doing it the way you described in your question.

However, based on the exchange so far, we will change the settings as follows.
1. Set the custom fields as follows
　Type: single picker
　Content: "Japanese name:English name"
2. Split based on ":" with smart value of automation
3. Only the English name part is used for subsequent processing.

[John Funk]

Thanks for sharing that - it really helps me to understand.

And I think the path you have chosen to go is a good one.