UPDATE: It’s a wrap for our Jira Service Management Ask Me Anything. Thank you so much to everyone for taking part and sharing your questions and feedback. Be sure to watch the Jira Service Management roadmap to get updates on new features. Lastly, please keep the questions and conversations going via Atlassian's Jira Service Management Community page. We look forward to continuing these conversations with all of you.
Emily, Jason, Liron, Vincent, and the whole JSM team
Hello Community members!
We’re wrapping up the end of JSM June with an Ask Me Anything (AMA) with the Jira Service Management product team. This is your chance to ask all your ITSM questions to our panel of experts. The hosts of this AMA will include our team of product experts, Liron Deutsch, Vincent Wong and Jason D Cruz.
As part of JSM June, participants in our AMA will also earn the JSM June Badge!
Here's how it works:
Add your questions below any time before or during the AMA. Be sure to take a look at other community members' questions and up-vote those that you find interesting.
At 8 am PST on Jun 29, 2021 you can expect to see answers from me and my team rolling in. Watch the page and be ready to add follow-up questions and discuss further with other Community members. We'll wrap the event up at 8am PST on Jun 30, 2021, but will be sure to answer any questions we didn't get to.
Another question I have is related to the complexity to configure screens. With the introduction of JSM, we now see:
To properly setup all the forms for those, you have to:
Are there any initiatives going on to reduce the overhead related to managing all that and streamline the process a bit more?
One of the biggest initiatives we are starting up right now is tackling this exact problem of configuration complexity. The ideal would be that a customer would not need to go through all of the areas you mentioned. We are striving to enable as much simple straight forward configuration in the project level. If you’re interested, we would love to share more and user-test some of our designs for these areas as they become available.
We are working hard on the ThinkTilt/Proforma integration and this functionality will come as part of native JSM in the coming months. The plan for the integration means that JSM customers will be able to configure forms to their request types easily and as part of request type configuration process. We will announce the finer details as soon as we get closer to the date.
What plans are there to make better use of Confluence in conjunction with JSD. Currently competitor products like Zendesk, ServiceCloud integrate a KB with the ability to search articles. Instead of just popping up little articles have a full blown experience. Instead of the very restricted ability as a "unlicensed user" in the associated Space is there plans to expand to fully leverage Confluence (including search!!). In many organizations it's not possible to open up the Confluence space to anonymous YET the same features would be/should be available to the unlicensed users of JSD.
Our KB strategy is to provide a native Knowledge Base experience in JSM for JSM agents powered by Confluence. We are also aiming to improve the article view experience in the customer portal.
Towards those objectives we have recently increased the knowledge article width in the customer portal so portal customers now have a better reading experience with wider space for articles and articles can be created with bigger images and wider tables.
We are currently working on enabling a view similar to that in Confluence in the JSM agent view including features like on-click zoom-in images, playing video in-line and rendering macro styles on par with Confluence.
Regarding search, portal customers can search for articles but we are looking to improve it. It would be helpful if you could give specific use cases in search that you would like solved.
Hi @Jason D Cruz,
How will this native KB experience in JSM impact customers who are using Confluence as a knowledge base with their service desks today? Will they have to / be advised to migrate to the native experience? Will they still need Confluence when this becomes available?
this was also mentioned on Team 21 and in the AMA afterwards. While details were scarce at the time it was mentioned that this was going to be a Confluence style editor experience but without having a true Confluence separate instance.
I do believe it's for environments where you only want a KB and not a true document management system.
I classified it as an integrated Confluence lite :)
Hey @Dirk Ronsmans,
I've had the privilege to participate in a feedback session about it. In terms of look and feel it is indeed very much as if you were in Confluence.
My question is mainly what will happen for existing customers and their Confluence instance. They are currently paying a license fee for their internal users who are keeping the KB content up to date. So, my 2 cents: when you add that functionality as a feature directly in JSM (in which plan? at what cost? ...?), there must be some plan and messaging for all those customers who are already using Confluence for the same purpose (as it is a good solution and there is no alternative as of today).
Will this be an incentive to get them off Confluence? Will there be a content migration track available? Will Confluence and the internal KB continue to coexist in the future?
The first version of native knowledge base within Jira Service Management (coming in the Fall) will allow all JSM users (even non-Confluence users) to create, edit, delete articles in the connected space from within JSM.
All details related to packaging and plans for existing customers are still in progress. However, there won't be any migration required as the native knowledge base within Jira Service Management will still be leveraging the power of Confluence.
We are running an Early Access Program for this and you can sign up here. Look out for an announcement and detailed FAQ sometime this Fall.
Our users want to be able to go to the Confluence space from the JSM to peruse articles, white papers. The lack of search for an unlicensed user in Confluence makes it really hard to give our users the full experience of perusing an entire KB. Anonymous users have search why can't unlicensed users?
I share the opinion of Patricia Francezi and I add a complement;
Hi @J_Acosta and @Patricia Francezi -iDev- ,
Could you share more context on your use cases for security in custom fields?
I can share that we are doing a lot of work behind the scenes to make custom fields easier to work with in general. This work is in progress.
We are also reviewing issue security and looking to make that a more user-friendly feature but don't have a timeline for that as of yet.
Hi Andréia, thanks for participating in the JSM AMA! This is still something we are actively scoping out right now and we do intend to work on it in the next few quarters. Please continue to check our public facing roadmap so you can follow along with new feature releases.
Another one I was thinking of is:
What's the idea behind Ticket Categories? Based on the Ticket categories you get a few default Queues but it seems then that only the items from the Portal are automatically triaged in those categories.
When you manually create an issue you seem unable to choose the ticket category.
Due to this we're having to look at multiple queue's to find all the issues (both portal/walk-in/phone sources)
will this concept become more streamlined? Or what's the bigger idea behind those ticket categories?
Hi @Matthew Day
Sadly I'm not talking about Request types :) let's see if I can illustrate it a bit more.
Right now within a JSM project you have your regular queues and then the "ITIL" queues which are prefiltered on the "Ticket Categories"
When you open for example the "Incidents" grouping here you can see that the filter for one of the underlying queues is prefiltered on a ticket category;
You now have the regular queues where you have all your freedom but you also have these grouped queues that go by Ticket category.
An agent might assume then that all his incidents are listed under the "Incidents" grouping but thats incorrect as when you create an issue manually you don't have the option to set that ticket category right?
Hi @Dirk Ronsmans, thanks for participating in the JSM AMA.
The idea of ticket category is actually to introduce the idea of practice into Jira Service Management. The product has concepts such as request type which controls the forms the customer sees and issue types that control the workflow, fields etc. However, we are seeing more and more customers use JSM for various practices such as incident management, change management etc.
By having ticket category, it allows us to start grouping similar practices together. These could be coming from different request types and also have different workflows but they are all actually the same practice. For example, with Change management, you may have multiple issue types for normal, standard and emergency change that each maps to multiple request types. With ticket category, we are now able to easily identify all of issues and request types that are for the Change Management practice.
With this, the few default queue is just the start. With ticket category, we are able to provide newer functionality and more opinionated functionality to the various practice. For example, in change management, we launched change calendar but in the future we could have an issue view that is better designed for change.
We currently map ticket category to request types as issue type is a cross project concept. The recommendation is for an agent to choose request type when they manually create a ticket which will have the practice attached. However, we are definitely looking into improving both the manual create experience and also finding better ways to connect the ticket category so situation like you mention wont happen.
Ticket category is still a very early concept for us. If you would like to speak more about this topic, our product manager working on this, @Jehan Gonsalkorale (email@example.com), would love to chat with you.
We should be able to create categories in this queue. It would improve the adoption of ITSM practices (even they are already ready to be adopted).
ITSM users are very tied to the "process names and what they mean in the service lifecycle".
Im also interested in give my feedback for this one, if possible.
Hi @Emily Dang ,
Thanks for the explanation. I'm curious to see how it will evolve then cause you mention
With this, the few default queue is just the start. With ticket category, we are able to provide newer functionality and more opinionated functionality to the various practice
From what I can gather then it would mean that Atlassian will decide which issue types will be grouped in to the default "process/practice" queues. How would that evolve if we create our own issue types but adhering to a certain practice? I would like to do that with Request type to a single issue type but if you need multiple workflows you currently can't have multiple workflows for the same issue type..
My main issue/concern was that it was controlled by the platform and we could not set the ticket category manually (or I missed it) which ment that you had multiple entry points for issues (either with the ticket category or without and then you get a fragmented view on the queues related to the practices (created through the portal or linked to the the Customer Request type field) and then other (non customer request type) issues would go in to the other queues fragmenting this view.
That might be something that I'm not 100% clear on yet. I would be happy to discuss this further or recieve more detailed feedback on it if possible :)
Hi Atlassian Team!
Thank you for taking the time to respond to these questions! Looking at the list I'm very interested to hear about a number of these.
One additional question I would add:
We have an internal development support team that handles escalations from our customer support team. They provide that level of interference so that our sprint team don't see as many interruptions.
We recently moved them to JSM, and for the most part things are going very well. What we would like to do is to make use of Organizations to be able to group our customer support members by product they support so that we can add all members of an organization to a request in case someone is unavailable another member can view the request from the portal.
However, the interface for adding customers to organizations appears a little clunky. I would love to be able to add users and groups based on existing Jira users, instead I'm going to be resorting to using the REST API.
Do you see any plans to make it easier to add users that are already listed in the "Customers" list to organizations?
Thank you for your time!
Hi @Jimmy Seddon, sorry to hear that the organization UI is a bit clunky. This feedback has been passed back to the team to see what can be done. The good thing is that our team does have plans to improve how customers and customer groups are managed as part of the later half of FY22. It is still early days so the team cannot comment on much detail at the moment.
I have been providing consulting services to many companies for quite a long time. I have been asked these questions many times.
We know that we have an opportunity to do something great as it comes to service catalog management. One of our biggest initiatives for this financial year is in this area. We are planning to have several releases in the future to help solve this problem more and more, one bit at a time. Stay tuned!
Atlassian recently acquired ThinkTilt, the makers of Proforma Forms. As such, we are working hard on integrating Proforma with JSM natively, meaning that you will be able (amongst many other things), to have dynamic fields as an OOTB feature as well. This should be available by end of this calendar year. We will provide more details closer to the time of release.
One more question - when Copy Issue Layout feature will be available for JSM?
Its rolling out for Jira Software, where, im my opinion is usefull, but not as important for admins as in JSM.
Considering the new ITSM template, its category and the need of creating Customer Request types to all of Categories to be in queues, creating CRTs are really high effort demand to have a common layout, using the new issue view....
Help us! :)
Im my opinion this is a Platform feature, and considering that we MUST have Customer Request Types, this feature should already be in place.
Hi team!! Thank you so much for providing this opportunity!
I have a couple of questions:
1. In JSM, it is told that collaborators (engineers/people from software team, who have access to Jira Software) can be assigned to tickets raised by agents. But how do we add collaborators to JSM ? We have only 3 roles under JSM, Admin, Customer and Service desk team, If we add collaborators under "Service Desk Team", Will the Atlassian charge us for collaborators , as they are assigned the same role (Service Desk Team) as Agents ??
2. Our company mail is under gmail, but with company's domain name ( firstname.lastname@example.org), so now under Email requests, "Connect a custom email account", if I plugin my company's mail id under gmail, it is not working. When I chose, "Other", it asks for Mail server, Protocol and Port.. Can I get help with these inputs..??
Thank you so much in advance.
Hi @Lavanya ,
I can’t speak towards your email problem, like @Dave Liao mentiones maybe that’s better for a separate question towards tte broader community.
As far as the collaborators goes. You can find more information here https://confluence.atlassian.com/servicemanagement/collaborator-660967501.html
a collaborator isn’t a real role. If you give a user with a JSW license permission on the JSM project they will get limited rights without a JSM license.
They cannot use JSM specific functionality (SLA, queues,..) or be assignee on an issue but they can add comments, be mentioned among a few.
Just want to share my experience:
I added the Collaborator to the role "Service Desk Team", but after adding, the collaborator can use all features that of an agent, I mean collaborator can be assigned to a task, can access Queues, reports and so on which should not be the case as per Atlassian support.
In Atlassian support it is stated that:
"Collaborators don't have access to the service desk interface (e.g. queues, reports and SLAs) and service desk projects appear as JIRA projects to them. They cannot work on issues, for example, logging work or transitioning issues."
I think, adding Collaborators doesn't work if we have free JSW.
BTW we have standard version of Jira Service Management and free version of Jira Software.
Thank you !!
Hi Apologies if this question has already been posted, but when will we have the ability to override the domain escpecially for the customer portal this is soo important to us. Right now we have two ITSM projects and its very confusing to our customers as the helpdesk URL doesn't bear any resemblance to the services.
This should be a priority we had this functionality on Zoho and JIRA to me is a far superior product but lacking in this respect.
This was scoped for the original custom domain work which not only allows the ability to override portal domain, but also to set a custom domain on your Atlassian site. However, there was a critical security problem and there is currently a team working out a solution while ensuring our cloud security standard is met. For more information and to keep up to date with the team’s progress, please follow the suggestion ticket Dirk linked above.
I hope this isn't too late but better AD integration would be amazing.
We use Atlassian Access for SSO licence management and provisioning. So AD groups can be read...
The use case is Jira already knowing who a user's line manager is for approval.
There are addons that fill this gap but honestly it's such a standard feature in other ITSMs that it should be available OOB.
Well you can always import your organization structure in to Insight and use that data to manage the approvals.
Since a user account in Jira doesn't really have any additional properties that you can fill adding the user details/information regarding the user in an Insight Schema is the easiest and can very easily be read through automation.
We just need to wait now for better AD -> Insight integration on Cloud
You can automate routing of approvals to managers from Azure AD/Okta using the Multiplier plugin on Jira cloud:
This uses post functions to pull in the manager from Okta and insert that into the Approvers field in Jira. See this for more details: https://docs.multiplierhq.com/article/17-how-to-automate-manager-approval-using-azure-ad-and-jira-service-management
Here's a quick 90 second demo:
Hey @Justin Boykin ,
Approvals is a standard feature in JSM.
You can configure a (or multiple) statusses with an approval step. On that configuration you can specific what field the approvers need to be read from and how many approvals are required for it to move on. (you can also specify what needs to happen when you decline).
This is not documented through the comments directly but the approvals will be shown on the ticket itself (in what step and by who)
The manager does not need to have any license assigned to them, they can simply be a customer and approve through the portal. (so they will need to added as a customer, but that's a best practice for all internal people if you are an internal service desk)
How that manager is set however is the tricky part, you can automate it if you have the source for that or someone can manually select the person who needs to approve.
How I handle approvals:
Generally I just let the submitter choose the appropriate manager. Most people choose an appropriate approver. Those that don't we either set a valid approver (if we know) or we kick it back to the user to try again (if we don't know).
If there are a small/fixed number of approvers then a dropdown is awesome but usually it's just a people picker.
The approvers go to the Portal and click Requests in the top right to see what's pending (or approve from their email alert). As Dirk said, none of these approvers have a JSM license.
Are enhancements for Multi-sort or KB on the roadmap? Loving JSM but missing a few things from previous service desks.
Hi JSM team,
My feeling is that the last year or two of changes (maybe more) has been geared at fancy new features with less focus on improving existing functionality, to the extent that in my view quite a huge list of core functionality remains incomplete. I'm not going to single out any individual points here - I am referring to the very broad strategy of adding dozens of bells and whistles while there are dozens if not hundreds of essential functionalities that have been waiting on "gathering interest" etc. sometimes for years.
I understand the reasons for the features-first approach (sales) but may I ask - is there any intent on taking a step back and solidifying the core system for some period of time? Is my concern above something you've seen/heard a lot of, and if so, could you put our minds at ease in any way?
Don't mean to be a meanie, I really do love Jira quite a lot (and am warming up to JSM), but I really want to be more comfortable if we're really going to make this a part of a medium-sized business. Thanks for any information you're able to share.
Hi Anthony - thank you for taking the time to participate in our AMA. Our team definitely hears you and this is something we’re committing to addressing in our new fiscal year, which starts in July. We will have a team dedicated to the core Jira Service Management experience and they will be focused smoothing out the interface and releasing some of those essential functionalities that I’m sure you are referring to. We also spun up an email team to focus on some long standing email issues as well. Please continue to check our public facing roadmap so you can follow along with new feature releases. Let us know if there is anything in particular you are looking for. Thank you so much for your feedback!
Hi, JSM team.
Here are my JSM cloud-related questions:
1. Can JSM customers submit an email address in the service request form and then that email address become a customer and be added to the portal automatically?
Case in point: customer A raises a ticket and fills in an email address; this belongs to a new team-mate of hers (user B) who doesn't have a Jira account yet; when the ticket is submitted, B's email address is used to create a "customer B" and customer B is added to the respective service desk. Customer B is then even added as a request participant (but that's an extra step).
2. Can customers directly reply to JSM email notifications, thus avoid opening the service desk and commenting under the related issue?
3. Is it possible that a single company have 2 Jira instances at the same?
Case in point: company A already has its Jira instance at companyA.atlassian.net; it now wants to have a second instance at companyA2.atlassian.net allowing users from the first instance to access the second instance too.
4. Can SSO be utilized on two or more different Jira instances?
Case in point: company A and company B have their own Jira instances: companyA.atlassian.net and companyB.atlassian.net. We want to allow a certain set of users from company A to access company B's Jira instance without having to sign up with company B's Jira instance, but use their existing AD accounts.
Looking forward to your suggestions. Kudos for the AMA initiative.
Thank you for participating in the JSM AMA! Here are @Jason D Cruz's responses to your questions.
It is possible for JSM customers to submit an email address in the service request form and then that email address become a customer and be added to the portal automatically? Please see this post for more details on how to get this to work. One thing to note is that you must have the correct Customer Permissions settings enabled for customers to add new customers.
Customers can directly reply to JSM email notifications and communicate solely by email based on project settings.
Yes that is possible, with the organization concept you are able to have your Company create multiple instances and control who gets access to what. On top of that if you are looking for run Jira across your organisation you can check out our enterprise tier - which gives you a licensing model where you only pay for user once in your organisation and they can have access to as many instance as you create in your organisation.
This should be achievable with Atlassian Access along with the organisation setup mentioned above.
Hi @Arnt Witteveen, thank you for participating in the JSM AMA! For Insight Cloud app database to Insight for JSM Cloud, export/import functionality to get databases from the app into the integrated version will be available by the end of summer.
For Insight Server/DC to Insight for JSM Cloud, we are working on it but it will be further out in the future. One of the things we need to look at, especially for server, is if and how we can preserve that history.
My team might use JSM to manage developer requests, but sometimes we'll want their ticket entry to go straight onto a different board. Is it possible for users to submit a ticket in a JSM form, have that ticket go straight to a different Project (Jira Software), but yet still be managed/visible in their own portal? It's important that there's visibility and collaboration between the dev teams and the requestor.
For more context, we have users without Jira accounts performing user acceptance testing, and we would want to utilize this for capturing bugs, but manage the bugs on a different project board and keep the JSM board for miscellaneous requests and bugs that are not a part of active projects.
Hi @A_J_ Apple, thanks for participating in the JSM AMA. There are a few ways this can be achieved.
While using JSM cloud, we are using a forwarding rule to send mail to JSM mail's address to create issues and comments. But we are facing the following issues:
1. For some tickets, the comments are not tracked by JSM and hence not reflected on the portal, For example, an issue was created with Email-Type Request and when someone replies on that email, ideally a new comment should be added to the issue/ticket created earlier but It is not happening and that comment is not tracked anywhere on JSM, neither as a new ticket nor as a comment in the existing ticket.
2. To resolve the mentioned issue, one of the members of the community suggested including email in the project instead of forwarding emails to JSM's ID, We tried doing that also but we are not able to get it done and was facing the attached issue.
Please help us resolve this issue and Let me know if I'm missing something.
Every incoming email is logged in the Processing Logs along with details if a request or comment was created or if neither action happened. This would be a good place to start to understand why tickets or comments aren’t being created.
If you already have a support inbox, we’d recommend connecting it directly to JSM. We support Microsoft OAuth and are adding support for Google OAuth in the next month. From your screenshot it looks like you’ve attempted to connect using the Custom Mailbox feature. Please check this document to ensure that you’re following the correct steps. There could be cases where the credentials are correct but the mailbox has 2FA or some other settings limit the ability of less secure apps to access it. The best way would be to reach out to support or I could help debug further.
hi everyone, wish you all well. Thanks Atlassian for giving us this opportunity to ask questions that we couldn't find a solution on forums. My questions are below:
1. Internal Comments
We use Jira Service desk/management (JSD) on-prem, all of our internal staff are counted as customers, and out IT team are the admin. We want to make sure all the customers can not see all the internal comments (which they can at the moment), all the customers are in the jira-access-users group, admins are in the jira-admin-user group, could we get some help please?
How do we set up an automation where it auto escalate priorities based on date created?
i.e. If a low priority ticket hasn't been touched for 3 days, auto escalate to medium priority.
I have read https://confluence.atlassian.com/servicemanagementserver/automating-your-service-project-939926334.html & https://support.atlassian.com/jira-service-management-cloud/docs/set-up-rules-to-automate-repetitive-tasks/ but struggling
Any support will be appreciated.
Hi @cissie chen, thanks for participating in the JSM AMA.
You should be able to do this by removing browse project access for your internal staff on those projects.
There are two ways - one way is to use the schedule rule trigger once a day and match the JQL of low priority + last updated less than 3 days, and action on that (this tutorial might be helpful - https://www.atlassian.com/agile/tutorials/how-to-escalate-overdue-issues-with-jira-software-automation).
The second way is to set an SLA to when the ticket is updated/actioned and when the SLA triggers, it fires an automation to escalate.
Hello New here and trying to take advantage of all features that Insight asset management has. my questions is, is there a way to create a dependency between objects based on a response? for example, i have Asset Details, inside of that i have Manufacturer, Model, OS. when i add some attributes to lets say for my Mac computers that asks for a manufacturer, when i choose Mac can i have other labels filter to only show Apple Models and MacOS? at the moment i have my dependencies set but it still shows all options so if someone pics Apple for Manufacturer and they move on to the next attribute which is Model it would still show all models even non Apple Models. Same goes for OS, it would still show Windows 10 Pro instead of just MacOS Big Sur.
Hi @Jose Flores _Jira_, thanks for participating in the JSM AMA.
It sounds like you would like to change the contents of an insight field based on the contents of another field. You can achieve this by utilizing Filter Issue Scope (read more here: https://support.atlassian.com/jira-service-management-cloud/docs/configure-the-insight-object-field/)
Filter issue scope will allow you to bring in the scope of another field in order to help narrow a search for a given field. The above documentation should outline further how you should be able to implement this in your specific use case.
The first 3 are the main request from customer coming from tradicional ITSM tools.
You took my questions. This is great! It would be so helpful if you could have the team assignment. I work with many projects and within those, there is usually at least one other person that is part of the project or even task. Please make this happen to improve not only the quality of the projects but will also help metrics.
Hi @Patricia Francezi -iDev- ,
I can chime in on a few questions.
We are exploring the concept of assignment Groups / Teams for issues and hope to have more details soon but we are some way out from releasing anything in-product.
We also have exciting developments coming out in the reporting space which should start flowing in towards the end of the calendar year which includes new out-of-the-box reports, visualizations, and the ability for better custom reporting.
Please continue to check our public facing roadmap so you can follow along with new feature releases.
Hi , Jason already answered most of this but just chiming in for missing bits:
as for (2): No current plans, but it is on our watch list. We will be evaluating this in the coming quarters.
(3) As part of bundling Opsgenie within JSM we are going to be incorporating more and more Opsgenie features as native in the JSM interface and in JSM objects. First step is around the Incident object in JSM, which will soon be able to include incident response features such as alerts, responders etc and be further connected in that way. Is this what you’re referring to?
3 - is not this.
SLO is a ITSM metric (very commom and useful) that composes the SLA.
Service Level Operations. The sum of SLOs between teams, areas, providers etc, should not be higher then the Service Level Agreed with customer....
So the tradicional ITSM tools monitor every "escalation", to monitor and control, and improve the metrics, including make a decision about modify the SLA with customer.
In another point of view, as a customer of a service provider, this would be my SLA with them, for example...
You can reach me for further explanation and scenarios if you prefer.
Thank you JSM team for this opportunity!
1. Will we see a tighter integration between what were Opsgenie parts and Jira Service Desk parts in the near future? (I frequently see a site switch and an extra authentication cycle.)
2. What is on the roadmap for Insight as part of JSM? When will we see a better connectivity to Insight Discovery?
Also interested when the JSM version of Insight will have auto-discovery available (if ever).
Side note: Having Insight showing in two different places with two different feature sets available is VERY confusing to end user. I think that update was poorly communicated and not thought out.
Yes, we are actively working on better integration between Opsgenie and Jira Service Management parts of the product. The first thing we are going to release in the coming months is around consolidating the Incident object across the two, which will unlock many capability benefits as well. Following that, we expect to tackle more of this with multiple teams. More updates on this to come in our public roadmap soon. As for the extra authentication, this sounds like a bug, are you able to raise a support ticket for this please? The ‘site switch' you’re referring to, sounds like the interface switch to Opsgenie, which is right now normal. We are working to solve these issues though.
Our team is working on automated connectivity as part of our ongoing efforts to improve importers and integrations with Insight Cloud. There is no specific timeframe yet but it’s an area of priority. Please continue to check our public facing roadmap so you can follow along with new feature releases.
As for incoming call routing, we are exploring a few possible avenues in enabling this in JSM, but do not have any concrete dates to share just yet. Stay tuned on this one please.
What are the JSM team's plans to align with the JWM team?
Conversely, what are the team's plans to further differentiate JSM from JWM?
JSM and JWM share some overlapping functionality (e.g. JWM's Forms feature feels like an upgraded issue collector with a JSM-like Request form editor) so anything that can be done to make JSM and JWM even more unique will make it easier for Jira admins to recommend solutions to users. 🙏
I'm pretty interested in JWM, and especially the 'alignment' part of this question!
I could see JWM being helpful for projects but my team also still needs to work in JSM (and I would like unified work visibility and metrics); spreading work across both sounds tricky for the fulfiller.
We are very interested in the answer to this question.
We love that the multiple product streams are producing so many great new features but it's a source of frustration so many are silo'd. Our internal service teams love JSM for the portal, request types, SLAs, etc. but really really want to use JWM's new feature set for calendars (and on a Kanban board!).
Here's hoping we eventually move away from all the three letter acronyms and JSW, JSM, JWM etc. coalesce more into just "Jira". Everything is on the menu, we would like it on one plate!
This is a great question. JWM is a new product but the JSM team is starting to work more closely with that team to streamline functionality, make sure that customers can clearly understand the difference between the products, and recommend the right one to your teams. Here’s how we see the difference between the two:
Jira Service Management is built for service management use cases and workflows that support service requests, incidents, changes, problems, and asset & configuration management. Teams like HR, legal, finance, marketing and beyond should use Jira Service Management for requests submitted by their “customers” (aka other employees) to help them with onboarding, legal contract approvals, finance approvals etc.
Jira Work Management is purpose-built for those same business teams but for back-office, project-based work. For example, if the HR team is implementing a new system, JWM is the perfect tool to track that work.
A lot of good questions here that I'm upvoting!
Other than that you guys are actually delivering on most of my long awaited enhancements. Still over the moon with the Change Calendar.
Hi @Liron ,
Thanks for the feedback. I'll be keeping an eye out for the ThinkTilt announcement and the updates regarding the internal Create button!
With regards to my first question, I'd love to explain it further cause I don't seem to be able to convey the functionality i'm missing properly :)
Using a workflow + automation might indeed work but would become very complex and inefficient very fast. The idea is that you have several Request Types (on the portal) which link to the same issue type (with the same workflow).
All these could be considered Service Requests (which might result in a Change later on) and would go through the same high level workflow. (e.g)
Open -> Awaiting Approval -> In Progress -> Resolved
These Service Requests however, would need to be handled differently once approved (so in the In Progress status) and then a secondary workflow (like in my screenshot) would become the leading actor until this flow is finished and then transition the request itself to Resolved.
This secondary workflow could then contain decision points/parallel tasks/mutliple teams but all in (dynamic) sequence.
If we were to do this with a workflow and automation that would imply that we need to translate each Request Type in to a seperate issue type to allow a Request Type to have it's own flow..
Also since automation isn't really a continuous process which holds a state it would require us to model the entire "flow" in to a very complex automation that has to validate all the steps each time (or at least more than we would like).
I hope this clarifies what I'm trying to achieve and I'm always open if there are alternative to implement this and of course available to discuss this further!
The example that I showed comes from ServiceNow (just happens to be one that I know that implements it like that) where a single issue type/process can launch multiple secondary flows (with even automations in the steps towards external systems, etc.. )
This has been a request for several customers and this is under consideration for our near-term roadmap. We expect to start working on this functionality by the end of the calendar year.
Please continue to check our public facing roadmap so you can follow along with new feature releases.
Hi Atlassians!! Thank you so much for providing this opportunity to us! We have a couple of questions related to Insights.
First question - How do we properly map fields for a CSV import to make sure we properly populate our informaton?
Second question - How do we make use of custom fields that have been created in Jira and have lists of values inside of Insights? In other words, can we "share" or use the custom fields already created in Jira without having to duplicate those fields in Insights?
@John Funk -> I've found that the only way to properly import a CSV into Insight without issue is by using Apple's Numbers app. They say that any UTF-8 format will work; however, Microsoft Excel formatted CSVs for UTF-8 failed for me all the time. I had a support session with a former Mindville staffer in Sweden that told me that was the best way. Luckily, we use Macbooks.
The 3 things that caught me out the most often:
Sample shot showing updates to purchase date of hardware entries (item 2 above):
Further to Johns question, is there training in the pipeline to specifically outline best practices for uploading using the insight discovery tool?
I have found it difficult to decipher how to extract exactly what you want and how to have it present well. In my case, I was looking at Asset management and although there are a few quick instructional videos out there but I was really needing some more in-depth assistance.
Hi @John Funk ,
For your first question, I'd love to know more about what are the exact problems you are facing. Is it that the formatting of the imported data is wrong? Are things not importing at all or something else?
More information on the concepts of importing files and creating object type mappings can be found here with a few examples. The documentation is for Data Center but is applicable to the Cloud CSV importer too.
To your second question, unfortunately, this is not possible. You would need to create new objects for each of the options in your current custom fields and then create an Insight custom field to show those new objects. However, once the work is done, it’s significantly easier to maintain than custom fields containing a list of values.
Hello JSM team,
Thanks for the opportunity to get answers during JSM June!
1. Do you plan to support security on Request Types? I mean to restrict Ticket creation for certain request types?
As @Patricia Francezi -iDev- pointed out it would also be good to have plans for "team assignment" along with agent assignment for requests in Queue
2. Also do you plan to support contextual information like getting a list of prior Request tickets created by the Requester so that it would be easy for the Agent ?
Can I expand on your first point?
Better permissioning around who can create different request types would be fantastic. For example only a person in the Marketting team can request a request type like 'Update the website'. It isn't something that should be available to everyone.
Even more amazing would be integration with Active Directory. So a user is given access to applications based on AD Groups, so you could personalise the user experience. So Jira would know what applications a user has access to and then offer request types that are actually relevant to that user.
Thank you JSM team for doing this!
To follow up on @LarryBrock question, when do you anticipate to release the REST API for the new Insight?
And when do yo expect to have the migration path in place to get objects in the old Insight over to the new one?
Hi @Mikael Sandberg - thanks for participating in the JSM AMA!
A better integraton with iInsight would be really fine, for example:
I was wondering how the experts would tackle the problem of too many HOT projects/service requests.
The team: Small team, works our own projects, supports other tech teams (software), handles tickets for infra stuff (jsm). High-level project details managed outside Atlassian while low-level tasks to complete the project are in software & jsm.
The pain point: The boss has a new high-priority request and we all know the routine, "what work do you want me to postpone?". I'm having trouble visually managing project tasks/timelines to push other stuff back for the new priorities.
My thoughts: I can get the work out of software so it's all in JSM (in progress). The first thing that came to mind was Visual Task Boards (from a previous vendor, though). I've thought about saying "we can only 2 P1 and 4 P2 at any given time". Curious about using JWM for projects (concerned about having multiple views to capture work from both locations).
What are your suggestions?
Is there any plan to increase the max limit on the number of fields that a single JSM Project can have? We have recently hit the limit in one of our mature Projects and it is a major nuisance to have to stand up additional Projects and break-out Request Types due to this limit.
Hi @Dylan Keyer ,
Thanks for your question, a very good one. Am I right in assuming this is a Team-Managed service desk (Next Gen) project?
If that is the case, it is not currently possible to add more fields per project but I can certainly look at how we might increase that limit. I definitely agree that it is a pain point.
If it is a Company-Managed (Classic) project, then I'd like to know how many fields we are talking about because I'd imagine it would be several hundred if not more.
Let me know, keen to understand this correctly, very much able to bring this into prioritisation conversations, although I obviously can't make any commitment at this point.
I have a couple of questions;
1. If a customer raises an Incident through the portal it will enter JSM but nothing will happen. I'd really like to be able to automate issues of a certain priority to "Create Major Incident" so that we can leverage the Alerting capabilities within OpsGenie. I've looked in Automation, but can't see anything there.
Is this possible?!
1a. possibility may be to automate an Incident to a Major Incident if it has not been touched for a defined period, based on its Priority.
Is this possible?!
2. I'd really like to be able to AutoAssign Incidents to a Team, preferably the team member that is on-call, rather than have to pick a specific individual.
Is this possible?!
3. is it possible to have different Clients to be able to raise Incidents / tickets through the portal but only see Applications / services that are applicable to them. We need multiple clients to use the portal, some use the same Application, some use different Applications, but we must keep anonymity.
Is this possible?
The work we are currently doing around merging Opsgenie incident capabilities with JSM incident capabilities are going to solve your first question, this is coming within a couple of months so stay tuned.
As for the other questions I am going to refer to my colleagues to answer.
Are there plans to allow using a Confluence Server space as a Cloud JSM Knowledge Base for the customer portal?
Currently, it is possible to create application links and then link a Confluence page in a request, but not the Confluence space as the KB on customer portal.
Do you have an estimated time for dark mode theme? I've been reading the community forums and see a lot of people complaining about using a plugin to be able to use a dark mode. Though I agree with mostly users when they say it should be native.
Hi Datán, thanks for participating in the JSM AMA! Currently in Jira Service Management we offer dark theme on the Opsgenie side of products such as Alerts and Major incidents along with its corresponding apps.
On the main Jira interface however, this is something we have been explored and spiked but it is currently on the backlog. You can follow the main suggestion ticket to get all the updates: https://jira.atlassian.com/browse/JRACLOUD-63150.
We are struggling to figure out how we are meant to manage lots of request types for a single issue type. As they all have the same workflow and are dealt with by the same team, we use the same issue type. However, when adding a request type we have lots of fields that we don't need. It would be much easier if all these fields started off hidden and we could then add them to the agent view in the same way as the request form. Much like team based projects.
This is especially frustrating when you add a new field to a screen and it them makes it visible to ALL request types that an agent sees.
Is there a way to make these fields default to hidden?
At the moment, it almost forces us to use lots of issue types which seems against the best practices. Can you help let us know how we are supposed to manage this properly?
We're facing an issue setting up "Email Requests". When setting up new email requests everything goes smooth during office hours but if we're setting up an email request off hours, the emails are not read by Jira. This happens across multiple projects and emails.
Back at 12 AM EST the emails are read and tickets are created. This seems a very weird issue. Is there any timing bracket set on email requests?
With the inclusion of Opsgenie, it seems like it would be great to potentially have incidents created in JSM automatically so that they show up in the incidents queue. I tried to set this up with automation but it was not very simple and the incidents were not hyperlinked in Opsgenie.
Also, will Opsgenie and JSM be automatically linked without the need for an API token in the future?