You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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.
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.
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 ,
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 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.
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.
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 (firstname.lastname@example.org), 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 :)
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.
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:
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.
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 ( email@example.com), 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 !!
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.
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.
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.
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.
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.
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 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!
Are enhancements for Multi-sort or KB on the roadmap? Loving JSM but missing a few things from previous service desks.
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.
Hello and thank you for this open session for questions,
In fact I have question about the security and the vulnerability of Jira confluence as software. Did you fixed the security problems raised recently?
As a customer I am worry about the use of the sensitive information to be stolen or to be used in wrong way by hackers.
I have read some articles about that that's why I am asking for more info about it.
As far as I know, this page (https://www.atlassian.com/trust/security/advisories) lists all publicly disclosed issues.
The last one for Confluence was Dec 2019. Might want to provide a bit more detail/specifics, otherwise this is a pretty vague question that will be difficult for them to answer in a meaningful way.
Hi Nour, thanks for participating in the JSM AMA! The link Derek mentioned above is the best place to see the latest publicly disclosed issues. Our team also address the vulnerabilities reported by Check Point Research here, https://community.atlassian.com/t5/Trust-Security/Vulnerabilities-Reported-by-Check-Point-Research/m-p/1734060#M405. Let me know if this addresses your question. Thanks!
Hi Emily & team,
I'm interested in knowing some more about certification:
Thanks, keep up the solid development!
Hi @Matthew Tutcher, thanks for participating in the JSM AMA. We’ll have 2 new Atlassian Certifications launching in July and August. The first is Managing Jira Projects for Data Center. There are no discounts for Community members, but Managing Jira Projects will come as a bundle with the related course, and costs only USD $100.
Training isn't so straight-forward, will have to do a bit of poking around: https://university.atlassian.com/student/catalog
This isn't JSM specific, but is there anything on the roadmap for promoting changes from the Sandbox to live?
Currently development takes place in the Sandbox but there is no good way to transport these automatically into production and there is manual effort to re-configure in production. This can mean that activities are missed or mistakes can be made.
There is a huge focus from Atlassian on customers being able to easily apply changes to their own products via git and other products... But then applying changes to Jira is to manually input changes into production.
Other ITSMs can do this via update sets.
Hi @David Meredith , nice to chat with you again!
Yes, we are calling this “data promotion” and it is on the roadmap but it won't happen for a while. In the meantime, we recommend checking out either:
Configuration Manager for Jira Cloud (still coming soon)
Our Product Manager @Matt Tse can answer any other questions you might have about this topic. Thanks!
Hi @jakorten, thanks for being part of JSM AMA! The two links below should help answer your question.
If I hide an internal IT Helpdesk project from the Help Center (currently used for an external-facing portal), is it possible to make the hidden project available to only employees to access/submit/update tickets to? I found this How to hide a project from Help Center but it doesn't go any further...
@Nick Savage projects are only visible to the customers you add on that project (and the agents who handle the tickets) so normally if you define your customers either with the internal employees or external customers the projects should only show for who you add
@Dirk Ronsmans Thank you. It would seem I'm missing something.
To clarify: By default all customers can view? I have to explicitly deny external customers from viewing? Would you please point me to where I explicitly deny external customers.
Project settings > Customer permissions shows the following
No customers are listed as added
This is the existing Help Center with customer service portal before adding my IT helpdesk project/portal
This is it after without hiding IT helpdesk portal/project
As who are you looking at that portal? As your own account (who has JSD application access? going by the NS in the top right corner I'm guessing so)
Your settings say "only customers who are added to the project can view" and your customer list is empty so a regular customer who can log on to your portal will not see the project.
You, as an agent however, will see all the projects on the portal that you have "browser project" permissions for.
You really need to distinguish between a customer and an agent and when a person logs on you need to verify if that person has agent access/browse project permissions.
Imho, as it looks right now, only users with browse project permissions will be able to see this helpdesk on the portal (so that means licenced agents) and you have no customers defined so nobody without a license will be able to see it on the portal.
This might take a bit far tho if it's not clear yet so not sure if we should split this from the AMA thread :)
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 ,
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.
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 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.