Richard Scholtes Success Champion

I would safe go for all out JSM here. It can do what all the other prods do with apps. And Standard lacks automation. No automation, no fun!

Hi @Nicole Jones-Campbell First of all Good luck with the future roll out. Aside all the good hints you got from Andrew, I want to give you a not so Atlassian related advice. Make sure you talk to those that should use it before you implement and make sure the management has a vision about your product you can align to.…

You can collect the addresses in that way, but there is no mail batch function in JSM. A function like this is more native to Statuspage | Atlassian. You can mimic this by a series of automation, but it will never be as good as a native function. As an alternative you can look for an add-on in the marketplace that gives…

can you give me a screenshot? I am not 100% sure what you mean by "automation system rules" Thanks

This is just relevant for customers with more than one site (e.g. example1.atlasssian.net and example2.atlassian.net). If those two sites had different billing contacts the update would give them each a different billing account. Single sites only have one combination of billing and technical account. That's just a…

this currently not possible. there is an open feature request for those "locked custom fields" https://jira.atlassian.com/browse/OPSGENIE-148 https://jira.atlassian.com/browse/OPSGENIE-338

Please check if the Tab is only on the Edit Screen of the issue Type or it is on the View Screen as well. As Closed Issues are often configured to a "view only" state.

Hi @Khalid Sheikh , the link between OpsGenie and Jira is generally done via the "Connected Apps" part in the "Settings" of OpsGenie. Although the syncing of assignments is not possible out of the box, yet. You can sync them with fetching the users name from the comment that the sync places in the JSM issue after the ACK…

Sure, just make sure you have a view screen and an edit screen associated to your used issue type. Then remove the field from the edit screen and keep it on the view screen. Tada! Field is not changeable by user anymore, but can be changed by automations or transitions inside the workflow.

The field "Assignee" is a system field in Atlassian and therefore not changeable in any way. The only way to put restrictions in place is to make it unchangeable by manual access and only change it via automations. But that would need you to have specified tasks for specified assignee and let an automation identify which…

Your current automation in the screenshot is just changing things in Linked issues that have the relationship "cloned by". I'm not sure if this is what you want to do referring to your text. If it's not what you want to do, I recommend to work with IF conditions instead of branching

You could also organize those users from the same domain in one customer Organization. Then you could the create the automation that if an issue is created, check if it is from Organization abc and if yes send the mail

The "Assignee" field in JSM is a Person picker field, so it will always be showing all possible persons. So would a group picker field. The upside of that is, that you don't have to administrate those fields for new persons or those that left the company. But there is a way to get this more specific, that would work if the…

I used to code and tweak on everything, until my wife would tackle me out of the office chair. I don't do this anymore. I start working later and I am more organized in my schedules. So most of the time, when the clock would tell me: "Call it a day, Buddy!" I already finished my daily goal and therefore can power down the…

Hello Stefan, yes. From the start the portal will be displayed in the language that the user has his account configured in. I am a German native myself, but because of Indian colleagues, my Atlassian Account is set to English, so I can always see the field names, that they see. Kind regards Richard

Hello Everyone! My name is Richard Scholtes! I got my first contact with Jira in 2019 while working in 1st Level Support and steering a 3rd party supplier that used Jira Software for job planning, Current status quo is that I successfully rolled out JSM (formerly known as JSD) as our new ITSM Ticket System, half of our…

Following the current scheme, no. Only alternative would be to change the customer permissions in your global permissions and NOT to allow everyone on the site to access the portal. Then you would have to sort the users out in the JSM projects manually and should get a group of users that are allowed to access the link,…

Requests are only visible by the author/reporter of the request and everyone with Customer Access to JSM that has been added as "Request Participant". This can happen as @Nikola Perisic showed in their post or via "Agent View" directly in the field.

As the link you can create still points to your Atlassian site, I would assume that you can only prevent users to do so, if you don't generally allow users with access to your site to access your portals. Do you manage the customers of your JSM projects manually or are the portals just open to all site customers?

I know this is old, but that's exactly what I would like to do. You already have an interface between JSM and OpsGenie and in JSM you have dedicated Jira Asset Field as Custom Fields. Can this be the source of transfer to OpsGenie? @Benjamin Paton 

As far as I got it, the product gives us more options in how we want to show Data to C-Level and even other organisations like Auditors or national authorities.

Why for Enterprise Only? Is it so expensive on your side or are you currently testing the performance?

as this is not an out of the box feature, I can just suggest a workaround like: Create a custom Field that is flagged by an automation, when the ticket is assigned to your first level group while it is transitioned to your "resolved" status Then just filter after tickets with this flag

As I ventured through the reactions here, you might to stress out from the start, that the main use is that you now can decide which of your Atlassian Access users see which of your JSM Projects in the main portal to guide them better, Because as I see it, that's simply what there is. No more, but no less either. 

I'm still gnawing on this bone, too. As the feature request regarding the automatic reminder seems to be taking some more time, I treid to put an automation in place. I surely could contact the approvers in some way, but it would contact those who already approved, too. So now I try find a rule that will remove those who…

Can you have this gadget display not only one date, but a day period like in MS Project?

I call this not solved. How am I to know why a mail address is "invalid" for JIRA? This error message is just rubbish. The mail-address is valid in terms of form, so that should not be the error. Why should I be guessing right now, what the real error is?

as I wrote, I already tried it out with my user, which has all the rights he needs in JSM and is of course fully licensed.

I think I'm not really understanding what you are suggesting. How should I - even if I successfully checked - define a comment to be public, if the option to do so goes missing as soon as I narrow the range of the rule down to Service Projects?

yes, just build a global automation rule that does exactly that step by step. It is almost self-explanatory. Choose "comment is created" as a trigger and afterwards a condition "linked issue" that shrinks the possible triggers to the related tickets you create with your other rule and choose "create comment" as the action…