Skip Workflow step based on a value within ticket

[Monica]

We have a case where depending on a value within our ticket we can skip a step in the workflow. Below is a picture of the field that holds the value "Requestor Employee Type", based on the value of that field is whether or not we would like to skip a step in the workflow. I looked into the automation rules but I can't seem to find a way to have the rule look at that value. 

[Kevin Patterson · Accepted solution]

Hi @Monica ,

This should be possible in an automation rule. It is difficult to tell in your screenshot but is Request Employee Type HII Mission Tech text inside a table in the description field? If so and assuming it is a text value and not a screenshot of a table you will need to use Regex to extract the value you are looking for and store it in a variable inside your automation rule. here is a link to help with the regex https://confluence.atlassian.com/jirakb/extract-content-out-of-description-and-summary-with-regex-and-automation-1157495262.html 

Inside your automation rule you will need to use the Create Variable Action using regex to get your data. I've extracted data from description before using this method but never data inside a table before so i'm not 100% sure if this syntax is correct but it should be close (it is looking for requestor employee type and then returns everything after this value until the next CRLF):

{{issue.description.match("requestor employee type\\s*([^\\r\\n]+)").find(1)}}

Once you have extract the value as a variable, you can use the variable as a condition to check before taking the Transition issue Action to the appropriate status. 

[Monica]

Hi @Kevin Patterson it is actually a table, but I will look into this to see if I am able to extract my information and store it in a variable. Thank you!

[Kevin Patterson]

Hi @Monica Just out of curiosity where is this data currently collected and how does it make it's way into the description field of a JSM issue? I typically see information like this collected in a JSM request type via a form or custom fields. 

Depending on your situation you might be able to improve your requestors experience by collecting this information in a request type that you make available through the helpcenter. Your automation rule would be a bit easier to manage as you wouldn't have to deal with the Regex extraction bit.

KP

[Monica]

Hi @Kevin Patterson we collect the date thru a confiform on a confluence space we have, then we take all that info using a PowerShell script and create the ticket in Jira.

[Monica]

@Kevin Patterson It seems like the Automation Rule option won't work for what we need. We been considering another option, transition - triggers, have you done anything like what I am trying to do using that option?

[Kevin Patterson]

@Monica - I've only used Automation rules to automatically advance status based on criteria when working with Jira Service Management. I do not believe you will be able to use a transition trigger to accomplish your goal. Triggers are more focused on keeping Jira statuses insync with Development tools like Bitbucket and Github.

Can you share why extracting the Employee Requestor Type value from description is not able to meet your needs?

[Monica]

Hi @Kevin Patterson based on I have done it just didn't seem like it was grabbing the date from the Table that is inside the Description.

After a lot of reading, research, and going over this with a coworker we have the feeling that maybe my issue is on how I am trying to extract the data. Here is my latest modification, maybe you can see something that I am missing:

Based on the log, it is telling me that my ticket did not match the condition

[Kevin Patterson]

Can you add a Log Action in your automation rule with {{issue.description}} in the log message. I suspect there are special characters in the description that might be causing you headaches with this. once we know what is there we might be able to adjust your compare, or even remove the chars completly with  issue.description.replaceAll

[Monica]

Here is what I get from Description on the log:

Description: *Who is Filling Out the Form*: User *Requestor Information* |Requestor First Name|User| |Requestor Middle Initial||Not Provided|| |Requestor Last Name|WorkflowTest| |Requestor Company||Not Provided|| |Requestor Email|user@hii-tsd.com| |Requestor Phone||Not Provided|| |Requestor Employee Type|HII Mission Tech| |Requestor Is Contractor?|No| |Requestor Username|username| *Sponsor Information* |Sponsor Name|Test Sponsor| |Sponsor Company|Mission Technologies| |Sponsor Email|testsponsor@hii-tsd.com|

[Monica]

@Kevin Patterson thank you so much for that suggestion, I can't believe I didn't think of that, here it goes:

[Monica]

Here is the text format:

*Who is Filling Out the Form*: User *Requestor Information* |Requestor First Name|TestUser| |Requestor Middle Initial||Not Provided|| |Requestor Last Name|WorkflowTest| |Requestor Company||Not Provided|| |Requestor Email|user@mail.com| |Requestor Phone||Not Provided|| |Requestor Employee Type|HII Mission Tech| |Requestor Is Contractor?|No| |Requestor Username|testusername| *Sponsor Information* |Sponsor Name|Test Sponsor| |Sponsor Company|Mission Technologies| |Sponsor Email|testsponsor@mail.com|

[Kevin Patterson]

I copied your string above into the description field of one of my issues and used the following regex to extract the Requestor Employee Type

{{issue.description.match("(?<=\\|Requestor Employee Type\\|)([^|]+)")}}

Give that a try and see if it works for you also.

[Monica]

@Kevin Patterson that did it!!! Now my second comparison is for the following 

|Requestor Is Contractor?|No|

It fails on that one, I assume that because I have a "?" symbol that will be an issue?

[Kevin Patterson]

Glad that worked. 

For you 2nd comparison you are correct about the "?". You will need to escape the regex interpretation of the question mark. You accomplish this by putting backslashs just before the question mark in your regex expression.

{{issue.description.match("(?<=\\|Requestor Is Contractor\\?\\|)([^|]+)")}}

[Monica]

I see, so with the backslashes is like telling regex to ignore the "?" mark?

[Kevin Patterson]

Yes, the "?" is also a regex command so we use the \ to treat the question mark as part of the string and not a regex command. For regex you only need a single "\" character to escape the question mark. The reason there are 2 "\" is because the first "\" escapes the Jira Smartvalue processing, leaving the single \ to escape the regex. It took me way to many attempts to figure out the last bit about needing 2 "\" than I am willing to admit :) 

[Monica]

Oh I see... wow I really can't thank you enough for all your help, you are simply amazing.

If you don't mind me asking, I see that on my original code towards the end it is very different to what you had. Would you be able to explain why that is, I am trying to understand it given many examples online have it done my way.

[Kevin Patterson]

Both of yours and mine are valid approaches, I Think the reason yours was not working as expected was that the Jira automation Smartvalues has some reserved characters that would have needed to be escaped. Most examples online do not account for this, which is why google searching and LLM bots might give you results that don't work in Jira Automations. You'll noticed in my example that I have \\ instead of the single \ in your example. Some characters are used in Jira Smartvalues that also need to be escaped so you will need to add a 2nd \ to accomplish this.  My approach uses a Lookbehind Assertion (?<=\\|Requestor Employee Type\\|) I do this just in case the text string "Requestor Employee Type" happens to be the value in another field. here is a good reference site that explains it a little: https://www.rexegg.com/regex-lookarounds.php

I hope this was helpful.

[Marc - Devoteam]

Hi @Kevin Patterson ,

To be able to achieve this the field value needs to be represented in a custom field.

All information represented in the description field is regarded as text, this doesn't matter if it is in a table or not.

If this values in a custom field you can built an automation rule that based on the field value triggers a transition in the workflow that by passes a certain status.

This transition has to be available or made available in the workflow

[Kevin Patterson]

@Marc - Devoteam - it doesnt' necessary have to be in a custom field. We can retrieve the value from the description field using Regex and store it as a variable with the create variable action. I'm just not sure how the markup used to define the table will impact the regex statement. 

[Monica]

@Marc - Devoteam It seems like the Automation Rule option won't work for what we need. We been considering another option, transition - triggers, have you done anything like what I am trying to do using that option?

[Marc - Devoteam]

Hi @Monica 

I don't have experience with that.

And if I read up, there is no option to use regex in a transition, on validation or condition

You could look at this issue, as it seems someone has been able to resolve to set variable based on text in a table and use regex for it.

Fetch-information-from-table-in-description-to-custom-fields 

I don't like regex options based on text values, as if anything changes the transition based on triggers will be invalid.

The same applies for using it in an automation.

From best practice, I would say store the information within Jira custom fields as that would provide a more stable solution, in my opinion.

You could even look to create a Jira issue direclty from Confiform, instead of a powershell script.

See: Creating+Jira+issue+from+Confluence+with+ConfiForms