Jira Automation Help: Dynamically Clear Fields based on Form

[Mathew Lederman]

Could use some help with an automation rule (if it's possible).

The Ask:

Allow customers to Request Again a service desk ticket they submitted in the past.Request Again clones the ticket, reopens the dynamic form, and allows the user to make necessary changes

• Ideally, these would extremely simple changes. For example, on a New Hire form, all the access is the same but the new user's name changes. 
• However, we have no way to stop customers from changing the location, access, devices needed, etc. All dynamic fields that change the fields showed or hidden below.

The Problem

Form fields linked to Jira fields necessarily copy with the form. If the linked fields are empty, the form fields will show empty to the customer.

If the customer changes a dynamic field from A to B, all of the fields tied to A still show up on the ticket and the agents see options for both A and B causing significant confusion. This also causes problems for reporting, analytics, etc.

The Solution

The process currently consists of 2 automation rules

1. Step 1 
   1. Trigger on field value change
   2. Clone Work Item
      1. Set a few fields
      2. Set new ticket as clone of original
   3. For recently created
      1. Set Request Type
      2. Copy form from Trigger 
      3. Reopen dynamically defined form
         1. GET form ID 
         2. PUT to Reopen form
2. Step 2 - Where I need help
   
   1. Trigger: On Form Submit
   2. Clear any form fields that are not on the newly submitted form - How can I do this???

If it clears all custom fields I, I can re-add those. If it clears things like Reporter and Summary I think I'm stuck.

Currently I'm trying to do some updates pulling from the changelog and clearing anything that wasn't updated with the last change, but that doesn't work because that may wipe out things where the user left the field alone.

[Marc -Devoteam-]

Hi @Mathew Lederman 

To my knowledge there is no option to clear a form or clear fields in a form.

There is no API endpoint for this.

You only option in theory would be to clone the issue, add a new from and the see if you can add form information from the original form on the new form.

But still and do get your point, but requesting a ticket based on an old ticket and cloning this, is not the way to go, as this can cause many issues.

If the form changes  in time or the request itself, you will get failures or incomplete information.

Then the dynamic setup will cause single points of failures you agents then need to solve.

Even in Enterprise ITSM, I won't to this an requesters just have to create a new request, if this feels like they have to fill to much information, then the question is are the forms correct for the customer?

[Mathew Lederman]

@Marc -Devoteam- cloning the issue, copying the form and opening the form for edits are the exact solution. I'm simply missing the last step: Delete fields from the original that were not submitted on the clone.

If you need to create a new Distribution List, there are 8 questions that the mail team needs to have answered. If, two weeks later, you need to create another DL with the same details just a different name and maybe 1 or 2 unique users, wouldn't it be nice to not have to repopulate all 8 fields, just the differences?

Now, think about onboarding a new user, where there are up to 140 questions depending on a variety of scenarios. In a department with high turnover, cloning the previous requests and just changing the name and 1 or 2 other key points saves a significant amount of time.

Happy to hear any recommendations to the contrary if you think this is a poor direction.

[Marc -Devoteam-]

Hi @Mathew Lederman 

There is no option to delete form information, even if the for is reopened.

There is no API endpoint for this, this is a manual action on a reopened form.

Recommendations; look at the questions are they really needed for creating a request like a DL?

Or even in overall, why are there for onboarding up to 140 questions needed?

Is there such need of detail on an onboarding request?.

[Mathew Lederman]

The form fields are linked to Jira fields, so I need to clear out the Jira fields.

The questions on the DL form include:

• Type of Request: DL, Shared Mailbox, General Mail Support - Select DL
  • Action: Add, Change, Delete - Select Add
    • Business Unit
    • New DL Name
    • DL Type (Internal v External)
    • DL Owner
    • Additional Info
    • Attachment

If you select DL > Change or Shared Mailbox > Add, for example, you're presented with different questions. I'm not sure how you can do much without any of these fields (obviously Additional Info and attachment are optional). 

My process works perfectly if the submitter selects the same dynamic options (DL, Add). But if they change the clone selections (DL > Delete) , I need to clear out the non-applicable Jira fields

The same applies to Onboarding. 140 is the maximum possible if you say 'Yes' to every possible option. Most managers fill out 20-30 fields. If the manager selects the same dynamic options, everything works. But if the manager changes even 1 dynamic option, there will likely be non-applicable fields populated which will cause lots of confusion.

To your previous point, if the form changes and cloned data doesn't copy over as cleanly, that's fine. We'll still have the fields requirements on the form and as long as the non-applicable fields are removed, everything proceeds normally.

[Andrea Robbins]

Hi @Mathew Lederman

I totally understand the reason for this, but maybe the solution would be something different. Just for data integrity purposes, it is not really recommended to clone tickets.

What you can do instead, is create different forms for different purposes - that way one form can have default values pre-set, so the end user only has to fill in the data that will change. You don't even have to set this info on the form if the user knows it'll be the same.

I've done this before for new hires for example using access policies all stored in assets. If the user selects the department as sales for example, then my assets (through automation) will find what policies/software access/hardware the user is entitled to. 

My point is that you may find a way to do what you want, but sometimes a simpler path is sufficient (presetting fields on the form, presetting fields on the agent side, or using assets as a database to know what those pre-set values should be).

Another example is like standard changes in ITSM. I have a standard change asset that stores the rollback plan, test plan, and implementation plan as it is the same each time it is submitted, so the only thing the user has to select on the form is a change template asset, the date/time, and the asset that the change will occur on (like server or other infra).

Hope this helps :) 

[Mathew Lederman]

@Andrea Robbins I really appreciate the response and respect the solution for a more simple scenario where things can be defaulted and/or assumed. 

This scenario is intended to support an enterprise-grade service desk with 120 different Request Types, 120 forms, 1000 different fields and 12k users.

We have a LOT of pieces already in place to pull in managerfor approvals, delegated approvers, workflows to bypass and/or accept approvals only in the approate scenarios, assignment groups, etc. All are based on a variety of highly dynamic rules. And we don't ask questions if we have any other way to detemojr the info.

This last piece would help save potentially hundreds of hours / month but it has to be dynamic.