Using a lookup table to convert custom field values from Project A to the custom values of Project B

[Chris Buzon]

Hi All,

I wanted to write an article / start a discussion on the new Lookup Table, and explain how it can be used in (what I think is) a common problem that would normally require several if/else branches. You may not need all of what I'm doing here, but hopefully it'll help someone.

Forgive my formatting.

Scenario: We run a Jira Service Desk where our employees can submit bugs and feedback for our products.  We don't really want to run this as a proper service desk with queues and responses, but we do want to use the features of the service desk to allow "Customers" (may not have jira licenses) to submit issues and ideas and then clone those tickets into the correct project, depending on the information provided by the customer. 

When someone submits a bug, we ask a series of questions, but the main ones are which product (iOS, or Android for example), and which "team" within those two products.   Our use-case for "teams/subsquad" is not important for the example, this could instead be some other custom field you wish to pivot on.

Operating system is a custom field with 2 options (iOS and Android) - which is used just to help us decide which project to clone the ticket into.

I've created a Jira automation rule in with the following skeleton:

(There are several other possible requests in this desk, so I am using IF/ELSE)

Capture the "Public" Version of the Team Name (This is pre-defined in the Custom Field Context for our service desk) and then store it in a variable.  You may use a different syntax for the custom field that looks like {{issue.customfield_12345}} or {{issue.customfield_12345.name}}, etc. 

Next, create a lookup table in this "if" branch.  These names are made up for the screenshots.

Next Create ANOTHER Variable, which we'll use to capture the internal name from the lookup table

THIS IS THE IMPORTANT STEP.  We will have 2 Variables from this point forward.

Pay attention to the smart value* part in the picture below.  I'm passing the name of the first variable we created, but it does not use the moustache brackets inside the parenthesis/function.  This is where my testing broke a lot. 
{{lookuptablename.get(firstvariablewithoutmoustache)}}  

You still need the moustache brackets, but only on the outside of the Smart Value* field. 

Next, I am cloning the service desk ticket into the destination development jira project (destination project is not a service desk).

This step is actually a bit harder than it looks.  You'll need to make sure the fields you're cloning are available on both projects, in the create screen for destination project - or it'll just succeed and not copying the data over.

I chose to not set the "subsquad"/Team in the clone action just for demonstration sake  -- you can do this in other ways. (that subsquad field is TEAM for our example, but we don't really call it that and I didn't want to make a custom field just for this demo)

You'll need to branch AGAIN (see below) in order to set the value of the field in the Destination Jira project using the new variable created.  Again, you can do this in other ways.

here's most of the relevant logic for this rule. You really, really should use Logging Actions to the audit log every time you create a variable, when the rule fails you'll usually see blanks in the audit log, and that helps you narrow down where you made a mistake.

So you want to:

1) set conditions (narrow down as far as you can) for this rule to clone the source ticket into a destination project.

2) create a variable to capture the source field data

3) create a lookup table to map source data to internal data

4) create a new variable using the {{lookuptablename.get(firstvariable)}} function

5) Clone your ticket (or the other methods of creating a ticket if you prefer) into the destination project

6) use the second variable to set the destination field value (remember the contexts for the custom field matter here.  Your destination project's context has to have the values you're intending to use!)

I really hope you get a chance to use this and it doesn't make your hair go grey!

Ask questions if you have any, or if I missed something in my explanation, which is entirely possible.

[Danny Morales]

This is great! I got it to work once but it's no longer working for some reason. I was able to skip the lookup table for my purpose and have it just pull {{issue.Team.name}} which gave me the team name that I was then able to use to set the field. Thanks again!