Automated Field Updates from JPD to Delivery Ticket without Global administration

[Mike Wilk]

I've been searching for answers on how to create an automation so that some of the field values from the JPD idea are copied to the newly created Delivery ticket in the destination Jira project. 

While I've found a wealth of information, almost everything I've found requires you to create the automation using the Automation > Global administration feature. In addition, almost everything refer to the Link Types = "Polaris issue link" but that's not an option I see listed for the When: Issue linked rule option.

My question is twofold:

1. Has the "Polaris issue link" option been replaced with something else?
   1. If so, what is the new option that should be used?
      
2. For larger companies that don't give project admins the ability to access the Automation > Global administration, is it possible to create an automation to update field on the Delivery ticket created from JPD?
   1. If so, does any documentation or demo videos exist with those details?

FYI - when you have an org that is large as the one I work for, they don't give elevated permissions to project admins nor do they have the capacity to create automations (e.g., they rely on the project admins). While I realize this is my org's policy, I have to imagine that other large orgs also have the same (or very similar) policies. IMO, it is a major drawback if people who are merely JPD/Jira project admins cannot create automations that will both save people time and reduce manual-entry errors.

Thank you in advance for any assistance you can provide.

[Nick Haller]

Hi @Mike Wilk ,

Hope that Article helps! I don't believe the Polaris issue link has changed recently. Having said that, there was a time where Engineering did change the link type - but I'm forgetting what it was changed to...

You could find the link type between your ideas and deliveries using the API on an idea that has a linked delivery. You can open  URL in your browser like the one below if you replace your site's name and the idea's key:

https://site-name.atlassian.net/rest/api/3/issue/KEY-123

Might look something like this:

As for the automation, the rule's Scope will need to touch both the Jira and JPD projects in order to work as expected. There realistically and unfortunately is no workaround to this.

[Mike Wilk]

Hey Nick,

First, I appreciate the quick response; thank you. Apologies for the long message that follows...

After reviewing the link to the Scope info you provided, it seems that it can only be configured through the Automations > Global administration option, which is why I can't seem to find the "Polaris issue link" type (see screenshot at bottom).

I guess the part of my question that you didn't answer is how those of us without access to the Automations > Global administration option (e.g., link label) can even create such valuable automations?

While I understand the need for security, it would be extremely helpful if project-level admins could at least define the automation scope for Multi-projects (but not necessarily Global as the implications could be massive). Even if it were limited to 2 projects, I think that would be sufficient (at least in my case). However, without the ability to set the Scope for an automation, we're stuck "between a rock and a hard place" while losing out on value of the JPD > Jira systems integrations/automations. 

Hopefully, you can understand how valuable this is to users that only have project-level admin rights and no way to get those with higher level permissions to create, test, and implement automations. I can't even begin tell you how many hundreds of complaints I've gotten from people who either don't want to manually update fields in multiple locations, or reports of data inconsistency when things don't match from JPD to the Delivery tickets that were generated (since the fields didn't automatically populate & someone forgot, missed, or incorrectly entered a value in a field).

Ultimately, I was hoping there was a workaround for those of us that don't have the Automations > Global administration option. Again, that would be very helpful for employees at orgs that don't grant that level of access and also don't build custom automations on request.

Now that I understand the problem preventing me from creating the automation, I realize that it's a tall order for you to change who will get access to setting the scope. However, maybe you can consider the following as future enhancements to solve the problem:

1. Change the location where the Scope is set for Single project & Multi-project automations (so it doesn't require that high of a level of permissions)
2. Create a way to request temporary/single-time access to configure the scope of an automation
3. Create a way to set the Scope of an automation by a project-level admin but have it send an "approval request" to a higher level to prevent any undue harm.
4. Alternatively, make it possible to configure the field mapping from JPD to the destination project when using the Create delivery ticket workflow & make it so that project-level admins could configure the mapping (similar to the import process).

For now, it seems like I'll have to deliver the bad news that we can't implement an automation and that manual entry will have to continue. 

------------------------------------------------------------------------------------------

Just as an FYI, I'm including the options that display in the Link types dropdown on the When: Issue linked option in the Automation > Create rule workflow, if a user doesn't have access to the Automations > Global administration. Although, I now realize that without being able to set the scope of the automation, it's a moot point.