Reference Fields Using Variable in Automation for Jira

[Haddon Fisher]

To support our quarterly planning process, our "roadmap item" issues have two sets of custom fields for each development team: one to hold their involvement in that roadmap item ([Team Name] Delivery Commitment), and the other to hold the size of that involvement ([Team Name] SWAGfest Estimate).

I have several automation rules which set one or the other field...for example:

• If a team is identified as the owner or a dependency for that roadmap item, that team's "involvement" field is set to "Estimate Needed".
• When a team provides an estimate, their "involvement" field is set to "Decision Pending".

This involves moving "between" the fields, and to avoid needing to maintain a lookup table per-rule, I am using regex string manipulation. This is hard to screenshot, but I've attached an example of how I am dropping\adding the right strings to create the name of the field I want to set, and then how I am making another variable called "JSON" which I then invoke in the third screenshot.

I've hit some edge cases that require me to look up the value of one field for a check before doing some action on the other. For example, if someone sets their "estimate" field to empty, I'd like to see if their commitment is set to "Tracking Only" or "Not Accepted" and if not, ask the team to review and re-set their commitment (i.e. you can't accept a roadmap item if you don't know how much effort it'll take).

My question is this:

Is there a way for me to tell Automation "this smart value or variable I am feeding you is not a string, it's a field reference"?

I.e. (and in super hacky mustache-ese) something like:

{{issue.{{variable containing field name}}.value))?

So I can go check the value of the other field? I suspect I could look it up using an API call, but that seems like total overkill.

Fig 1: Using Regex to get the new field name from the old.

Fig 2: Using the field name variable as part of a JSON update statement.

Fig 3: Invoking the JSON update statement to update the issue.

[Bill Sheboy · Accepted solution]

Hi @Haddon Fisher 

If I understand your scenario correctly, you want to just-in-time (JIT) get a field value, selecting that field based upon another reference.

As far as I know, there is no JIT interpretation of smart value expressions by-field available to customers.  If there was, rules would be even more powerful...and honestly, quite risky, unpredictable, etc.  (Last year, I experimented with this very idea quite a bit trying to build dynamic, tiny charts for emails in a rule and it never worked out :^)

Two possible workarounds:

• As you note, use the REST API endpoint to perform a work item search and specify only that exact field in the fields parameter, and so that will be the only one in that attribute of the response
• And the messy one: build a delimited, Created Variable, with all possible fields you may want to "get", adding their field name in the equivalent of key / value pairs.  Then split() that back into a list, and use a dynamic regular expression with the match() function to get the correct pair for the desired field, finally using text functions to extract the value.  This is a variation of the dynamic search method from an article I wrote last year.

Kind regards,
Bill

[Haddon Fisher]

Hi @Bill Sheboy! Thanks for the response!!! 

Inner monologue: Holycrapholycrapholycrap it's like saying "Some help would be useful here" and seeing Superman land on your front porch. KEEP YOUR COOL MAN.

Yes, I think you have the gist of the problem I'm describing, and seems like if I did want to do this truly dynamically, I would need that API call. Oh well.

The main thing I am trying to avoid is maintaining lists or mapping tables in the rules themselves, which I think excludes the second suggestion....it doesn't happen all the time, but we get enough team changes that I don't really want to own maintaining those lists even more than I already am.

I'm going to try and use only Jira API's to do this in my first pass (this seems like the type of thing lots of people might find useful) but I've also considered standing up some kind of internal mapping service; I'd still need to maintain some kind of list, but at least it would only be in one place.

I would at some point be curious to hear more about why you think this could be risky - I am functionally doing this right now in my rules and outside of some screwy human behavior it's actually working pretty well. Not saying that we all couldn't find ways to make it dangerous, but I am not sure I see how it's inherently so.

[Bill Sheboy]

Hi @Haddon Fisher 

FYI -- one way to try that second approach with less maintenance is to call the work item read endpoint, and then create that key / value pairs string using {{issue.fields}} as text for the source.  Although it would get messy quickly for structured fields: users, ADF, etc. 

The risks I noted were for this scenario:

GIVEN a dynamically-created smart value expression (e.g., with fields, functions, etc.) defined as plain text (i.e., unvalidated by the automation engine when the rule is defined)
WHEN something happens
THEN execute the dynamic expression

For get / set field scenarios, this would probably be safe, but not with functions in the expression.  Otherwise, I could imagine several unsafe outcomes walking all over data, halting rule executions, tricky to understand rule errors, etc.

Theoretically, one can do this right now by building a new rule using the automation REST API endpoints from inside of another rule, and then doing something that triggers this rule.  Possibly, one could even make self-modifying rules...although I have not tried that.

[Haddon Fisher]

@Bill Sheboy 

FYI -- one way to try that second approach with less maintenance is to call the work item read endpoint, and then create that key / value pairs string using {{issue.fields}} as text for the source.  Although it would get messy quickly for structured fields: users, ADF, etc. 

This is an interesting idea...the field names will always have a standard pattern, so it would be possible to regex them all out. I may keep this in my back pocket because....

Theoretically, one can do this right now by building a new rule using the automation REST API endpoints from inside of another rule, and then doing something that triggers this rule. 

Mind. Freaking. Blown. I have always wanted a "global variables" table I could use for Automation rules; lets see how far I can get.

THANK YOU!!!!!

[Haddon Fisher]

@Bill Sheboy I took a crack at building a second rule for this using the "Incoming Webhook" trigger. I _really_ like this concept because I thought it would be a solve for a lot of possible challenges but I found the inevitable fly in the ointment lurking around the response.

The "Incoming Webhook" trigger has no concept of a "derived" response; it will generate a flat HTML 200 to acknowledge the request, but that's it. This means you can ingest the data and process it, but to send it back you need a "Send Web Request" action, which sort of precludes the "globally available mapping service" I was looking for.

I'm going to keep poking this to solve for the one use-case I have in hand, and maybe look at some kind of if\then solution to allow this to solve for a few more. 

[Bill Sheboy]

Yes, that is a limitation for rules: there is no concept of a function / subroutine callout to another rule.

Instead, you could try using the REST API endpoint to get the metadata, or an example work item, and thus have a list of all of the fields.  Then use that structure to build the mapping information in a created variable.