Mikael Sandberg Community Champion

You have to have Jira admin permissions, then go to Settings > Issues > Custom fields. From here locate the field and then click on the three-dot menu on the right and select Contexts and default value and from here you can edit the options.

If you click on the avatar with the plus sign on it you should have an option for unassigned.

The short answer is no, Forms will always be displayed below any Jira fields in the request form.

Hi @Kurt Maurer, Welcome to Atlassian Community! Go to Rule details and check Allow rule trigger and see if that helps.

Hi @Alberto, Welcome to Atlassian Community! Your board should show an avatar to unassigned like this: And yes, you could change the URL as well, you would then want to set it to" https://xx.atlassian.net/jira/software/projects/xx/boards/xx/backlog?assignee=_unassigned_

The only time you would replace the smart value with the actual account ID would be if the user you want to @ mention is not in a user field on the issue. But if you have a field for lets say, stakeholders, the markdown text would be: [~accountid:{{issue.Stakeholder.accountId}}] 

You should not add your actual ID if you are the assignee, you should then use what I added above: [~accountid:{{issue.assignee.accountId}}]

Hi @Fremie, Welcome to Atlassian Community! The way I would do it is using the web request action to get the members of a project role and then add the members as watchers to the issue. Automation doesn't have access to project settings, so using the REST API is the only way to go.

Hi @Chris Shepro-Stein, Welcome to Atlassian Community! Yes, you can configure your project so only specific ones are visible to customers, it all depends on if you give them access to the project or not. Have a look at this KB for more information, Limit Jira Service Management visibility to customers on portal 

Yes, it is possible, but you have to use the markdown text and know the user's AtlassianId in order to do it like this: [~accountid:{{issue.assignee.accountId}}]

Yes, it is possible to have a mix of different tiers for the different Atlassian products.

You could do this with automation. You can either configure the automation to trigger on a specific event, or manually trigger it. You can learn more about automations here.

Hi @Costina Anghel - Iliescu, Welcome to Atlassian Community! JQL out-of-the-box does not allow you to create nested filters that includes the epics and the associated issues, you would need an app that extend JQL in order to do that. For example JQL Tricks or Enhanced Search can both do this (I have used both in the…

Hi @Matt H, Welcome to Atlassian Community! You should be able to run it as "Automation for Jira" But my recommendation would be to not use legacy automation, instead you should try and convert them to the new automation instead. Some of the default legacy automations also exists in the new one, you can find those if you…

You can do this with automation. You would need two automations, the first one would get the key for the Epic and the second one would be to add the comment to the ticket. It would look something like this (very simplified): First one Second one

Even if it is a custom field it could be a locked field, and based on the message you cannot make it optional. Your only options are to remove the field completely from the screen, hide it and give it a default value, or leave it as is.

You could store that in the user properties, and access it via automation and smart values, similar to this article describing how to store the user's Slack ID as a property in Jira so you can DM them via automation.

Which field is it? In the case of the summary field you cannot make it optional, and the only thing you can do with it is to hide if from the form by giving it a default value.

You can add/remove issue types by going to the issue type scheme that the project is using. Have a look at Associate issue types with projects for more information. 

The second automation would look something like this, with a if/else condition for each of you statuses And you should probably add a condition in the if/else block that also verifies the status of the epic and only transition if the epic is not already in the specified status.

Correct, the above was just an example. I would probably have two automations, and in the Epic branch make a web request to the second one that looks up the lowest status.

@Justin Thiel Yes, just use smart values to do it, the assignee would be {{issue.assignee.displayName}} and the customer would be the reporter.

@Jennifer Dragan it is available, but it depends on how you set up your swim lanes. If you leave it show it based on stories it will not show the count, but if you select any of the other options it will show the count. 

You can make the fields required on the form by clicking the checkbox. But fields like Summary cannot be made optional, hence the informational text when you hover over it. The only thing that you can do with the summary is to hide it and give it a default value. No, the request form cannot be shared across multiple…

You can do this using automation, the rule would look something like this:

Hi @pamela pennati, Welcome to Atlassian Community! To unarchive the project, go to Settings > Projects > Archive and locate the project in question. Then click on the three-dot menu and select Restore. 

Hi @Justin Thiel, Welcome to Atlassian Community! You can do this with automations, if you go to Project settings > Automations and look under the Library tab you will see an automation for that called "Resolve issues due to inactivity" that you can use.

You could do this using a scheduled automation that checks for issues that are waiting for approval and then send it to Pending approvers. The automation would look something like this:

Hi @Aracely Uresti, Welcome to Atlassian Community! Check your workflow to see if you have a validation that makes the actual start field required, and also check your field configuration if that field is set to required. 

If you need to add request participants via the form you would have to use a different custom field and then use automation to copy that over to the request participants field once the request has been created.