Referencing to a lookup table key with smart values

[Hilco de Lathouder]

I want to send out an email to a dynamic list of recipients, started via a manual triggered automation. The recipients depend on the value of {{issue.affectedServices.name}} which holds the Service name.

I have a lookup table called emailMapping with some email addresses, like this:

Service One : email@domain,email@domain
Service Two : email@domain,email@domain

When I reference to the service as key of the lookup table, it comes up empty. So  {{emailMapping.get( issue.affectedServices.name) }} returns nothing. I also tried adding accolades around the second variable but that didnt help.

just calling issue.affectedServices.name also gives the expected value (e.g. Service One)

 If I use {{emailMapping.get( Service One) }} it works and the value is returned.

What am I missing here?

Thanks in advance.

[Bill Sheboy]

Hi @Hilco de Lathouder -- Welcome to the Atlassian Community!

Is your Affected Services field a single-select, custom field?  If so, the currently selected value's name is likely:

{{issue.affectedServices.value.name}}

and so the table get() would be this:

{{emailMapping.get(issue.affectedServices.value.name)}}

That assumes two things:

• affectedServcies is the correct smart value for your field.  You may check that using this how-to article to find the supported smart values for your issue: https://support.atlassian.com/cloud-automation/docs/find-the-smart-value-for-a-field/
• The key entries in your table exactly match your single-select field values, in spelling, spacing, and case.  If they are different they will not match.

Kind regards,
Bill

[Hilco de Lathouder]

Thanks for the response. I fixed it by first creating an extra variable called affectedServices and assigning {{issue.affectedServices.name}} to it.

Next, i could use {{affectedServices}} in the rest of the automation. Works like charm.

Hilco 

[Bill Sheboy]

Ah...this is one of those cases where the automation's parsing order seems to be preventing getting the value before the function call to get()...and so the value passed to the function was null.  The same thing can happen for dynamic fields, such as those from marketplace addons, linked issues, etc.

What you did is a common workaround for that: first store the value in a variable so it can be looked up, and then use that plain text value in the function.

[Emile Helegbe]

I don't know why but I can't make it work with the same example. I set the variable affectedServices to Service One. And when I try to log with {{emailMapping.get({{affectedServices}})}} I'm getting the following error message:

Unable to render smart values when executing this rule:

Failed to get value for emailMapping.get({{affectedServices: {{emailMapping.get({{affectedServices}})}}

What needs to be fixed? Please note that {{emailMapping.get("Service One")}} is returning the correct result

[Bill Sheboy]

Hi @Emile Helegbe -- Welcome to the Atlassian Community!

Once an expression is inside a set of double-curly brackets, no additional ones are needed.  Please try making this adjustment:

{{emailMapping.get(affectedServices)}}

Kind regards,
Bill

[Emile Helegbe]

Wow it works now! Thank you very much

Is there a page with all those tips? What I've learnt today are:

- Don't put space within the double-curly brackets

- Don't put a double-curly brackets within the double-curly brackets

[Bill Sheboy]

I have found no single source for tips on automation rules.  Experimentation helps, and reading examples in the documentation and solutions to community questions.

Perhaps also see these articles I wrote on learning more about automation, including some more advanced topics: 

• https://community.atlassian.com/t5/Automation-articles/Automation-concepts-How-to-ask-a-community-question-or-not/ba-p/2683827
• https://community.atlassian.com/t5/Automation-articles/Automation-concepts-Learning-to-write-and-use-rules/ba-p/2901393
• https://community.atlassian.com/t5/Automation-articles/Automation-concepts-Dynamic-searches-within-a-list/ba-p/2834235

[Emile Helegbe]

wow this is very helpful. Thanks Bill and Happy New Year :)