nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How to trigger a screen

Zekai Huang

Hi All,

I am trying to understand what can trigger a screen like this.

Screen Shot 2023-05-01 at 2.55.45 PM.png

I know that both task creation and status transition can trigger this. Is there another way?

For example, can we do it via a manual automation action? We want to have some custom action without relying on third party app. Having it in the status transition is fine except we don't want to actually change the original status.

Thank you,

Zekai

Accepted answers

Trudy P Claspill

Hello @Zekai Huang

You cannot cause a screen to be displayed to a user through an Automation Rule. The fundamental functionality of Automation Rules is to execute all steps without user interaction once the rule is triggered.

Jira does not natively provide any other method to cause a screen to be displayed.

Can you tell us a bit more about your use case? Perhaps we can suggest some alternative solution.

All comments

Trudy P Claspill

Hello @Zekai Huang

Jira does not natively provide any other method to cause a screen to be displayed.

Can you tell us a bit more about your use case? Perhaps we can suggest some alternative solution.

Zekai Huang

We have a few different use cases, some of which were asked in the past from a different angle, but all can benefit from this. To name a few:

1. We are trying to simulate something like "Add PIR" but for a different type of item. We don't like the "Link Issue" experience because we have 10+ relationships and we also want to trigger additional automation. Can the "Add PIR" be customized? that could be a nice workaround as well.

2. We want to display some instruction, implication when user update certain fields from the intake field.

Thank you.

Nic Brough -Adaptavist-

I'm afraid your use cases do not change the way things work. You can't associate screens on arbitrary actions that do not normally need them.

If you were to move these actions into your workflows, so that they become part of the path to being done, you can add screens (and more) to them, but that's the only way to add screen use to a Jira system.

Zekai Huang

The problem with workflow is that it stays in that status, which won't work for my case either.

Zekai Huang

On a related note, is it possible to use the workflow screen to create an issue (e.g. a task) in a different project?

Trudy P Claspill

I don't believe that is possible. The screen you present during a workflow transition is for updating the issue being transitioned.

You might be able to use a workflow Post Function to create an issue, with the help of a third party app.

Or, if all the minimum required information for the new issue is contained in the transitioning issue, then you could do something like add a label to the transitioning issue, and use an Automation Rule to detect the addition of that label (or the self reflecting transition) and create the new issue in the other project using information from the original issue.

Zekai Huang

I was hoping this is supported out of the box, which is seemingly supported with the built-in "Add PIR" feature, that allows you to select an issue type in a different project.

But yes, I can work around this using some automation.

Thank you for all the replies, @Trudy P Claspill .

Kevin Christmann

You can use a workflow screen to create an issue in another project. We do it but it is in a pretty complicated manner. We also use Jira Assets (which requires Jira Service Management Premium) to do this. I think, however, that you might be able to do it without Jira Assets.

Here is what we do:

Upon transition we fire a screen we created.
That screen contains custom fields that asks the user A) what project to create in desired summary C) desired description
For us, those custom fields are Jira Assets fields. Where we store detail about our Projects including thigns like Project Key, the Issue Type to be used for that project etc.
Then in our automation we essentially do the following
1. Trigger = issue transitioned to <status you choose. We made one called "Spawn Request">
2. We check if they provided desire summary and description. If they did we put that into a variable we created. If they did not, we take the summary and/or description from the original ticket (using Jira smart values) and put that in a variable
3. Ultimately we use a Clone issue action that clones the issue into the project that was chosen and all of the other things I mentioned above. Here is a screenshot of our step for that. You can likely ignore the attachments piece.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-service-management-cloud

jira-service-management