How to set a custom field based on Reporter's email address

[Robert Levine]

Most of my JIRA requests are coming in from email, but we refer to clients by their clientID instead of by their domain.  (IE - CompanyName1 -> CL1; CompanyName2 ->CL2)

Is there a way to set a custom field called "Client" based on the email reporter's domain? 

For example:

Case:

Reporter = JoeSmith@CompanyName1.com

Then

ClientId = CL1

Case:

Reporter = FrankJones@CompanyName1.com

Then ClientId = CL1

Case:

Reporter = JaneDoe@CompanyName2.com

Then 
ClientId = CL2

etc.

I understand I'll have to map the Domain to ClientID manually somewhere, but I don't know another way to do it.

[Bill Sheboy]

Hi @Robert Levine -- Welcome to the Atlassian Community!

I cannot discern if you are using Jira Cloud or Server/Data Center; I am going to assume Cloud...

If you have just a few email address domains and clients to parse, you could extract the domain and use if/else conditions to set the client.

If you have a lot of clients, and you have tools to easily maintain entity properties, you could set the client ID as a property at the user level, or make a lookup table at the project level, and parse them from the list.

https://support.atlassian.com/cloud-automation/docs/jira-smart-values-users/#Entity-Properties

Kind regards,
Bill

[Robert Levine]

Thanks - I am using JIRA Cloud.

I am having trouble figuring out WHERE to extract the domain and use the if/else condition.

If I go into my Project's Automation Settings and select Create Rule and create a rule for then the Reporter gets updated, I don't see a place where I can parse the domain and create the if/else statement.

Or... even better, I have no idea on how to make a lookup table and parse from there (but will do some digging into how to do that).

Either option would work  - I just have to figure out how to do it.

[Bill Sheboy]

First...how is your rule getting triggered: when the issue is created, or when the reporter is later assigned, or something else?  That will help to pick the rule trigger.

Once you have the reporter set, you can use the text functions to split out the domain to then test with conditions, such as with substringBefore():

{{issue.reporter.emailAddress.substringBefore("@")}}

Perhaps try that in a test rule and write it to the audit log first.  That will help you experiment when implementing the rule.

[Robert Levine]

It will be when the issue is created, because the reporter will set when the email is received.

For issues raised via front-end or re-assigned, I can create a 2nd set of rules.

I'm still having trouble finding WHERE to enter the code to do the if/else statement.

Thanks for all the help!

[Bill Sheboy]

Again, if you have a lot of clients I would advise against the if/else type of rule due to the maintenance challenges.  That noted...

How about something like this, using the Create Variable action to save the result before testing in conditions...

• trigger: Issue Created
• action: Re-fetch  (This is important for the issue created trigger...when followed by conditions...as timing problems may cause the rule to start before all data is present.)
• action: Create Variable
  • variable name: varEmailDomain
  • smart value: {{issue.reporter.emailAddress.substringBefore("@")}}
• if/else condition
  • advanced compare condition:
    • first value: {{varEmailDomain}}
    • condition: equals
    • second value: CompanyName1.com
  • action: edit issue to set the client ID to...ClientID1
• else/if 
  • advanced compare condition:
    • first value: {{varEmailDomain}}
    • condition: equals
    • second value: CompanyName2.com
  • action: edit issue to set the client ID to...ClientID2

• ...

Please note: Automation rules are limited up to 60 component parts, and so this type of rule will only work for up to 28 client checks:

1 trigger + 1 re-fetch + 1 create variable + (1 if/else condition + 1 edit action) X 28 = 59

[Robert Levine]

Yes, definitely would need to go the lookup table route.  More than 30 clients at this point.

I still don't see where to create a lookup table, even though the Atlassian instructions say I could find it in the Issues settings.  And I'm an admin for our Atlassian products and have access to everything.

[Robert Levine]

So... maybe lookup tables are an add-in?

Is this what you were talking about:

https://marketplace.atlassian.com/apps/1214700/lookup-manager?hosting=datacenter&tab=overview

[Bill Sheboy]

Although there are probably addons for this capability, I was noting something a bit more home-grown using:

1. create a variable in the rule with all of the name|key pairs (e.g. CompanyName1|CL1, CompanyName2|CL2), use smart value list filtering to extract the match, and then parse out the client id; or
2. entity properties to do the same as #1; or
3. define a single-select custom field which contains all of the values as name|key pairs, grab it with the REST API, and then search

#1 should be easy to set up and try.  #2 and #3 would be more difficult to do and maintain.

If you can find/use a marketplace addon that may provide a more maintainable approach for this use case.

[Robert Levine]

Option 1 seems to be the best approach here, but I have no idea how to create variables and use a smart value to pull them out.  If you can give a small example, I'm sure I could follow the logic and reproduce.

1. create a variable in the rule with all of the name|key pairs (e.g. CompanyName1|CL1, CompanyName2|CL2), use smart value list filtering to extract the match, and then parse out the client id; or

[Bill Sheboy]

Hi, Robert.

After testing I learned that the match() function cannot accept a variable as a parameter, which is needed for your scenario because you want the client ID, not just the domain value.  What I suggested will not help solve this.  Sorry if this caused any detours for you to resolve this.

Your next steps may be to investigate the Atlassian marketplace to learn if there are addons for calculated fields to help.

Kind regards,
Bill