Updating a field when a specific component is used.

[Pfohl Jason]

I want to update the description field when a specific component is added to an issue after its created.

I can do this with automation if the component is used when the issue is being created. Is there a way to automate this after the issue is created, if the creator forgot to add the component while creating the issue?

[Bill Sheboy · Accepted solution]

Hi @Pfohl Jason 

Using a second rule with the Field Value Changed trigger for the Components field, one could detect using the field changed smart values for the specific values added, and use a Smart Values Condition to test that case: https://support.atlassian.com/cloud-automation/docs/jira-smart-values-issues/#--fieldChange--

What do you want to do to the Description field if someone removes that Component value later?

Kind regards,
Bill

[Pfohl Jason]

Bill, 

Thanks for the response. I would want the Description field to have no change if the component is removed. 

[Bill Sheboy]

Thanks for that information.  Please try creating that second rule to learn how it helps.

[Pfohl Jason]

Bill,

The second rule provided the update to the description field when I added the component after the issue was created. When I remove the component the description field does not remove the information that the automation added, which is what I want.

The new issue is that if I readd the specific component it duplicates the update into the description field. Any suggestion to prevent this from happening?

[Bill Sheboy]

What changes are you making to the Description field?

Perhaps you could add an additional condition to check if that change has already been made to avoid duplication.  For example, using a Smart Values Condition to check if it contains specific text.

[Pfohl Jason]

I am adding specific text of information that needs to be provided for the issue:

What:
• What are the transactions/authorization object that is needed?
• Will this allow them access to any sensitive data that might pose any business risk and may need to be controlled (Kindly Elaborate if any)?
• Who will need access (what roles should be updated)?

Where:
• In which landscape do you need the access? 
• In which box (config test client) would you like to perform the testing?
Who: The user ids of the testers (primary and backup) who will be testing the changes?
When: By when is the access needed?

Do you know how I would set up a condition to check if this has already been added to the description field?

[Bharat Kalia · Accepted solution]

hi @Pfohl Jason - Thank you for reaching out to the community. It seems like you want to do two different things which can be achieved by two set of automations - 

1. Trigger - Issue created , Condition - Component field is not empty and then you can create multiple branches based on what component field value was set and you can update the ticket field description. 

2. Trigger - Field value changed. Condition - Component field is not empty and then you can create multiple branches based on what component field value was set and you can update the ticket field description. 

If you always want the components to be present you can make it mandatory on create that will make your automations easy. 

Please let me know if this helped, I can guide you further if you need help with the automations. 

Thanks,

-Bharat

[Pfohl Jason]

Thanks for the information. 

The second rule provided the update to the description field when I added the component after the issue was created. When I remove the component the description field does not remove the information that the automation added, which is what I want.

The new issue is that if I re-add the specific component after deleting it, it duplicates the update into the description field. Any suggestion to prevent this from happening?