Mikael Sandberg Community Champion

The automation is really simple, it will look something like this: This one is manually triggered, so just change that to a scheduled one (once you saved it you can run it) and use a similar JQL as part of it. Please note that you have more than 1000 tickets that do not have the resolution set you would have to change your…

The guide you are referring to only applies to Assets in Data Center. Assets in Cloud do not have automations as a separate feature, you would have to use automations in the project in order to update an object when something happens to an issue.

The status and the resolution are two different things. In the first screenshot you included of the status you do not see the checkmark that you can see in my screenshot, and that means that the resolution field is not set. And because the resolution is not set your created vs resolved will show every ticket as created and…

Hi @Carina Manent, Welcome to Atlassian Community! When your tickets are moved to a resolved status, are you also setting the resolution, either manually or via a workflow post function? If you look at a resolved issue you should see something like this: That field is what controls if Jira/JSM is considering a ticket as…

@Hermeus {{issue.original.targetend}} is not a smart value unless you have an assets field called original with an attribute called targetend. What are you trying to do?

Hi @Sean Scale, Welcome to Atlassian Community! You have to retype their name, or at least start the @ mention with part of the name. Comments cannot use smart values, that is only available in automations. 

Hi @MidnightExe, Welcome to Atlassian Community! Once you create a custom field you cannot change the field type. Your only option is to create a new custom field with the correct type, and then either do a bulk update to set the values based on the existing field or use automation to do it. 

Anyone that have access to the PR can complete the task, and back in the days I used Bitbucket it was not possible to see who completed the task, not sure if that has changed since then...

Default pull request tasks are not similar to Jira tasks, they are more like tasks in Confluence. You can add them as a checklist for the pull request, and you can prevent the pull request from being merged unless all the tasks are checked off. At my previous job we used them just like that, as a checklist that had to be…

Agents and JSM admins will have the same view on the front end when it comes to queues, tickets etc. The added things that the admin will see is under project settings. Collaborators will only see the tickets similar to what you would see when going to a Jira project and the list view, nothing else.

The Service Project Customer - Portal Access has to be set in the project permission scheme, if you remove it from any of the permissions you will get the error above. That is not what allow your user to see the project or access it from within Jira. You should look and see what other permissions this user is included in,…

Hi @Roberto Chacon, Welcome to Atlassian Community! You can learn more about the roles in JSM here. There are basically 5 different roles, JSM admin, agent, customer, collaborator, and stakeholders. Stakeholders with have the lowest access, they will only be notified if you use the Incident management feature available in…

Hi @Cameron Ogden, Welcome to Atlassian Community! The short answer is no, this is not possible. Currently you have to have Jira admin permissions in order to access Global automations.

The short answer is no, you cannot increase the 100 issue limitation, that is a hard limit. So your option is as you mentioned to reconfigure your JQL so it returns less then 100 issues.

Ahh, I forgot about that, thanks for pointing that out @Bill Sheboy. I changed my reply accordingly. 

If you only have one open sprint at the time in the project then you can use the openSprints() to find the issues that are still open. There is no trigger in automation that can get the end date of the sprint, but you could work around it by using the scheduled trigger and then use the smart value as @Bill Sheboy mentioned…

Hi @Yasmine Oloufa, Welcome to Atlassian Community! This is a public forum, so you should be careful when adding company information here. I removed the URL from your post. You would need an app in order to do this. There are a couple of them available in the Marketplace, I use Custom Charts and it allows you to add a…

Hi @[deleted], Welcome to Atlassian Community! Structure is an app that has been added to your instance, and I am not sure that Structure support dark mode yet. Folks from the app vendor is on here so they should be able to answer if/when dark mode will be supported. 

Hi @Gustavo Bunheirao, Welcome to Atlassian Community! You need to check the filter used by both of the boards, my guess is that it is too broad so that it picks up issues from both projects and that is why you see the same issues in both boards. If you would remove project B issues that belong to that project would be…

When you use the "Share settings with an existing project" it means that you will share the configurations of issue types, workflows, screens, fields, permissions, and notifications. The use case you specified above would not work because if you make a change in project B it would automatically take effect in project A as…

No, the form will be shown as part of the request, similar to this: So the only thing you would need to include in the notification is the customer URL using the {{issue.url.customer}} smart value.

Hi @Peter Morrisey, Welcome to Atlassian Community! When you attach the form to the request it will be available on the Portal, but it will not send a customer notification. So if you want that to happen then you will have to add either a comment component or send email to the automation in order to notify the customer.…

You also have OnLink in the Marketplace that you may want to take a look at.

If you want an iPaaS that have integrations with Jira and Workday then Workato would be the way to go. Another option would be to use Tray.io, but it doesn't have an integration to Workday, so you would have to be able from Workday to trigger the workflow in Tray.io some way. We use Workday and most of automations we do…

Have a look at this user guide, it covers how to use Confluence for your knowledge base.

Hi @Timbo, Welcome to Atlassian Community! Does the form field already have field values that are different from what the Jira field has? The form cannot add new values to the Jira field, so when you link a Form field to a Jira field it has to have the same values. The only way around this would be if you take the value…

That's because you have spaces in the sprint name, so try this instead: sprint = "{{sprint.name}}"

Hi @Christopher Reynolds, Welcome to Atlassian Community! If the automation triggers on Start sprint then you can use {{sprint.name}} as part of your lookup issues to get the issues in the sprint. The lookup issue JQL would look something like this: sprint = {{sprint.name}} 

Hi @Christine, Welcome to Atlassian Community! No, automation cannot move a ticket to a different project, but you could clone the issue to the new project and then either link the two tickets or close/delete the original one.

When your tickets are moved to the Completed status, are you also setting the Resolution field either as part of a post function in the workflow or via a screen? The created vs resolved is relying on the resolution field, not based on the status. The resolution will tell JSM if the ticket has been completed or not. If you…