-
Suggestion
-
Resolution: Unresolved
-
1,746
-
53
-
-
NOTE: This suggestion is for JIRA Service Desk Cloud. Using JIRA Service Desk Server? See the corresponding suggestion.
Problem Definition
Currently, when users go to Settings -> Request types --> Edit fields --> Add a field, Request Participant field is not in the list even they've added this field to the issue type by editing the create screen for this project..
Suggested Solution
As a user, I'd like to display Request Participant field in the Create Issue screen in customer portal.
Possible workaround (limited)
It is possible to add the Request Participant field to a Form (Project Settings > Forms) which is then displayed on the customer portal; however, you cannot create new participants using this field, and due to security restrictions, help-seekers will not be able to search for existing participants.
Why this is important
It would save a considerable amount of time to be able to add participants while creating the ticket instead of sharing it later.
Workarounds
- Share the ticket with the request participants after the ticket is created.
- Create a custom 'User Picker (multiple users)' field and add a post-function on the 'Create' transition on the related workflow to copy the values from the custom field onto the Request Participants field. You can find details at How to add Watchers or Request Participants during issue creation.
- is related to
-
- Closed
-
ENT-1624 Failed to load
- relates to
-
JSDCLOUD-2428 Request Participant Missing from Create issue Screen
-
- Closed
-
-
- Closed
-
- Closed
- links to
- mentioned in
-
Page Loading...
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
[JSDCLOUD-1511] Allow adding Request Participant field into Request Form in Customer Portal
Please. I can't believe that I just had to create an automation as a workaround for this.
Another feature that DOESN'T EXIST IN JSM for no reason whatsoever other than they didn't think to add it for some reason.
It's so frustrating - if you're lucky enough to see this before you buy JSM from Atlassian DONT DO IT - Nothing you expect to be included is, and then you have to pay for all your Jira software users to have a JSM add-on because they can't be bothered, or decided not to, separate the 2 products so you must pay for the total users of either Jira Software or JSM (for us we have 45 Jira Software and 14 JSM) for an add-on to add something so essential to their Premium priced product. They just scam you and increase prices because they decided to build something new that no one asked for.
This is exactly what I was looking forward. I got very excited when I saw the issue was updated 10 hours ago. I got very disappointed when I saw that the issue was created nearly 10 years ago.
Hi everyone - a quick note to say that we have tentatively added this to our roadmap in the next 6-12 months. While we don't have exact dates yet, we understand its importance and will keep you updated on our progress.
Thanks,
Sam
JSM Principal Product Manager
Very disappointing that this basic function is not supported in the Cloud... I highly recommend to make the Request participant field usable again!
Unfortunately, this issue is not on our short or medium-term roadmap. We will be revisit this issue again in another 3 to 6 months.
This was written almost 16 months ago... please, reconsider this highly voted feature (as forms are not always the suitable solution)
Hi - is there any update or re-consideration of this request? It is quite easy to use the workarounds but wondering if this is not possible still due to the security restrictions. Thank you
When is this obviously sought after feature going to be considered @Sam Knight??? The last note from over a year ago said you would revisit it in 3-6 months. This is an appalling effort. Do better.
There is an option to create customfield User Picker (multiple users), add it to request type and copy this field with postfunction into Request Participant field in Create transition.
@frederik,
Luckily Atlassian is not sending rockets in space. I think they are good in making a profitable business model which make people hesitate to gonna use a product of a different company because they are not listening to their community.
@atlassian, what to say about this? When is this feauture request picked up instead of stupid UI AI elements that no one asked for it?
Launching Rockets into space and fly them back so we can re-use them. "Share feature" today's to high to achieve for humans. Jesus Christ.
Really basic feature, makes the initial communication so much harder than it should be.
How has this not been implemented yet?
So silly to not have such a basic feature and on top of this you mentioned that is not even on our plans for 3-6 months.
Very disappointed about this in general.
Our company just (finally) moved from on-prem to cloud, this is an unfortunate loss in functionality, something so basic - this is a collaboration tool, right? Adding after the fact is an extra step easily missed by requestors that they used to have the ability to do.
Atlassian needs to re-add this feature and leave it to your customers' Atlassian admins to work with their Security teams to use it or not. Thanks.
Should reopen this ticket, as your support just sent me this...
Hello Tyler,
Thanks for reaching out to Atlassian Support!
My name is Bruna and I'm the Support Engineer that will be working on your ticket.
Unfortunately, it's not possible to have the Request participants field in the customer portal when creating the ticket. However, we understand that this functionality would be very helpful, so we have an open feature request for this matter, as you can see below:
- Allow adding Request Participant field into Request Form in Customer Portal
We cannot say when this feature will be available exactly, but we encourage you to add yourself as a watcher of the feature request ticket to follow up on its progress, hit the "Vote for this issue" button, and provide any feedback you might have on the comment section (make sure you're logged into the system).
Just got referred to this feature request by support, and was incredibly disappointed to see it's not even being considered. This is such a basic and standard feature.
Simon-
Could you help us understand how this functionality exists in Server but not Cloud?
Unfortunately, this issue is not on our short or medium-term roadmap. We will be revisit this issue again in another 3 to 6 months.
It is possible to add the Request Participant field to a Form (Project Settings > Forms) which is then displayed on the customer portal; however, you cannot create new participants using this field, and due to security restrictions help-seekers will not be able to search for existing participants.
We will continue to consider this request as we look at improvement to the request configuration and portal.
Thanks,
Simon
JSM Product Manager
In my opinion it cannot be denied that Jira lacks so many basic (and mandatory) features. Moreover usually Atlassian does not care. Taking these problems into account Jira is waaaaay overpriced.
Its a shame that this isn't implemented yet.
+1 required, needed, mandatory item
Cloud migration strategy of Atlassian products didn't resolve the delay to have a new feature or an enhancement...
On Server, we could find plugins to workaround these kind of ask, but on cloud most of plugins are limited, due to the architecture (or will) of Atlassian Cloud... and it's just more expensive with less...
Sorry, but today I encounter too many limitations and frustration on Jira Cloud versus Jira On Prem. It's exhausting...
This issue is from 2015 and is stilll active so customers clearly want. Saying that after 7.5 years the solution is not "straight-forward" makes me laugh. This request is in the File 13 queue. 
Not being able to add participants to requests has beeing a huge issue here. A shame this is not possible.
I hope you start considering a solution soon.
Susan. I've been here for quick a bit of time. I just have a different mindset than you concerning these things. The feature request management system Atlassian lays out is quite clear. Taking the time to understand it may give you a little bit of a shift your negativity towards them. It would be great for Atlassian to chime in!
Hi Peter, perhaps you're new here, but I"m not. The writing is on the wall for this one that it's not going anywhere, and I wouldn't hold out any hope that Altassian will respond.
Susan, your interpretation of "Not Being Considered" is NOT aligned with the actual definition Atlassian provides for this status. Skipping over the fact that the "resolution" in this ticket is "Unresolved" and looking at the definition may put some folks at ease. If you hover over the status of "Not Being Considered" further context is displayed that states the following:
"Whilst we appreciate the potential impact and value the issue may bring to our customers, we will not be working on it in the foreseeable future. We will review this ticket in a year to see if our decision has changed."
I applaud your efforts as a community leader but perhaps the votes on this issue are too low in comparison to other requests to be considered. Perhaps it is more of a technical hardship to produce this solution as it stands against the other 3000+ feature requests Atlassian has lined up. Of course, Atlassian will have to step in here to add more context behind why this is being postponed as my statements are pure speculation.
Peter, when the status is "Not Being Considered" that means it's NOT on the radar. I am a community leader and I have done everything I can to highlight that this request should be addressed and still I'm getting nowhere.
Lynne, thanks for your feedback..."I don't think you should be telling others that it shouldn't be a must have for them.". However, that was not the exact context behind my statement nor was it accurately what I said. My statement was directed towards others who've insulted the development group directly by implying that they are "lazy" or demeaning the process in how these feature requests get selected. Since my comment yesterday they removed the specific insult however I see this behavior throughout all these forums and don't think it's right.
The facts are that there is a functioning workaround for the time being and a support group that will help you accomplish it. So the product is not preventing us from accomplishing the goal of adding participants at request creation. The platform allows us to create custom fields with few limitations and impact to performance. However, if your suggesting having this ability is somehow counterproductive, then I will have to respectfully disagree.
Overall, Atlassian has this feature request on their radar, it's our responsibility to pass it around the community to gather more interest so they can prioritize it accordingly. In case you didn't notice, the request is not closed, instead it's paused with the intention to circle back to it in the future. For those that are really passionate about getting this added, simply make sure you do the work to make it visible to others in the community so they can vote it up.
Lynne, I agree 100% with you. I already have put this workaround in place both to add watchers on regular Jira issues and to add Participants in JSM. What I don't understand is that on Jira server there was a Jira Watcher Plugin (free) that we used for years where we did not require a custom field, automation (or post workflow functions which is how I did it). It became defunct in Server just recently and obviously there was never a cloud version. But somehow someone made a free, supported plugin many years ago that did exactly what this issue is requesting and yet Atlassian can't do the same? That's what I don't understand.
Peter, I totally agree that we should not insult the team who undoubtedly work very hard and I agree with most of what you say. However I don't think you should be telling others that it shouldn't be a must have for them. There are too many occasions where people have to implement workarounds adding countless custom fields to get what they need. I personally will implement an automation for this but am a little disappointed that I have to add another custom field to our ever growing list.
For those that may not be aware, you can accomplish this by creating an automation rule within your project. The logic would be able to copy the value from a custom field you create and place on your request form to the participants field. Talk to support and they will go as far as to create the rule logic for you which is very helpful.
I think comments insulting Atlassian are NOT professional or constructive. Software development is never as simple as flipping a switch. Those of us in technology should have enough common sense to know this and exercise a little empathy for the amount of effort Atlassian puts forth. Comparatively at this price point, this product is best of breed and allows already a lot of customizations for your organization. Although this would be a nice to have feature, it's nothing to lose sleep over.
Oh, this is a feature that would definitely add more value to Atlassian's tools
This seems like such a simple thing and there is a known workaround, I just don't understand why it isn't a priority. Atlassian, please, please reconsider.
Hi all,
This is not something that we are planning on working on at this point in time. I agree that it is useful and would like to see it enabled in the product, but it has been deprioritised compared to other initiatives.
Best regards,
Jehan Gonsalkorale
Product Manager, Jira Service Management
Not tested this out, but I just had a thought, as a workaround I wonder if it is possible to create a small form with watchers and request participant fields, linked to the actual fields and add it to all request types? I will try and test this when I am back in work Monday.
Looks like they took that solution down, here is the web cache version:
Couldn't translate it fully since it is a cache
Dear Jira SM team: you are not considering this feature, although there is even a documented workaround for that? Really?
Voting for this feature. Working on a Service Desk where the CC To field does not notify those in there unless they are a licensed Service Desk Agent of the project. Upon research, I see the Request Participant field should allow those notifications even if they aren't a licensed user so I go to add that field to the Request Form and its not an option. So frustrating. The field is of course properly linked to the create screen so it should be an option to add to the form. The workaround of having the user go back in and share the request after its created isn't the most efficient way to do this.
For context on what I wanted to accomplish with this: https://confluence.atlassian.com/servicemanagementserver/adding-request-participants-939926441.html
Cloud version should get this update ASAP. It should not be that hard to apply this feature in the issue creation screen. Unnecessary workarounds are being built for something that is actually working on the server-side.
Please re-visit this issue this year.
We use this feature daily in our Server environment. I'm hoping we don't have to resort to creating a custom field with a picker and an automation for something that is already a feature in Server today. Adding a specific person on a new request is very important to our current processes.
Has this request been reviewed since December of 2020? Is it still in the "Not Being Considered" state?
Agree this is needed - We have been able to implement a bit of a rough workaround by having a user picker custom field, and then using automation to copy that value over to Request participants. Not perfect, but it is working okay. I don't understand what about this functionality is so difficult to implement.
Come on Atlassian. This is working just fine on Server and yet not Cloud? Two years+ since the last update of Not being considered.
How come we can all do workarounds by adding in a custom field then in the post workflow copying that custom field to the request participants? And yet you can't program that?
WORKAROUND with automation feature: (needs premium to work reliably)
Use the automation feature like so:
Trigger: Issue created
Condition: only applies to the tickets you want it to
Action: Copy the field value of a multi people picker field into the request participant field
'Key People' is the field i use for my workaround here: (edit: imagine a nice picture explaining how to do it, it does not display for me)
It is not very practical to create the ticket and add the participants afterwards. it is a waste of time. Please prioritise this improvement.
It has been almost 12 months since you updated this request. If we can add the requested participant to the issue, I'm not sure why this can't be on the request form.
Terrible, we need to send an email to everyone and that will create a ticket for everyone, instead of just creating a ticket from jira. This needs to be fixed
A new assignee has been given to this issue. Does this mean it's going from "Not Being Considered" to worked on?
More than 5 years to say that it is not in the roadmap, is not a good time as "resolution time".
This functionality is offered by a simple email, I have a hard time explaining to Jira agents why it is not possible to do something like this, in the end, they have to go to email.
Disappointed.
Don't understand why the same issue on the Server version is considered a bug and has been fixed https://jira.atlassian.com/browse/JSDSERVER-2428
Why can't the same fixed be applied to the cloud ?
I could've worded it better. Was trying to make the request submission and adding participants a 1-step process. Am building out the first JSM desks, trying to minimize comments like "our old system used to do X". Thanks for the reminder.
@Joshua Mathews
To be clear, users can add other participants to requests via the portal (via the Share with button), but only after the issue is created. It's asinine, I agree, but your comment suggested maybe you didn't notice?
I think Jira might be the only service desk where a user can't CC a teammate/manager on a request.
Since so many other helpdesks can do this, it doesn't seem like it's that complex. Please have the ability for the submitter to add "participants" via the service desk portal.
Wracked my brain for a couple hours trying to make sense of why I couldn't add this field. For those of us trying to promote portal usage as the norm vs. email, this is a huge barrier.
Please FIX (it is a fix honestly, not a new feature as it is available in the on-premise solution I believe)
Hello,
Very strange situation, we have button "share with organization" but don't have "share with customer or participants" into Create Issue screen in Customer Portal. I hope it will be new feature. Please review it sooner.
Regards,
Petr.
is not like this is a brand new feature that has to be added from scratch.... they just have to configure the field the same as all the other fields in the system.
what a joke
@Aleksandrina, I agree and it is especially strange since they fixed this in Jira server early last year, right before my company migrated to Jira cloud.
Hello,
This bug is since 2015. Are you kidding?!
Are you planning on resolving this anytime soon? This is causing so much inconvenience for all of our employees!
Why is it so hard to fix?
We discover this issue post migration. post migration the request participants was still in the list of fields supposed to be visible on the customer portal but indead it was not working.
For us it's really bothering. we have tried to get rid of email and forcing the user to go on the portal when we were on the server. And now that we have migrate, or we have to go back to email or to add it on a later step on the portal? That is a pity as some users are really lazy and didn't go to that second step on the portal.
To be honest waiting 6 to 12 month is too much, for me it's a bug as it was working on server and the migration process didn't give any alert for that. it's not anymore a new feature request when you "force" users to move to the cloud. Please review it sooner
Thanks, Liron. Yes, we can chat about that last one in more detail. I met with Jehan G to discuss that one too (if you want to ask him to share the recording).
pwalker1730297261 - really appreciate your words here. It's definitely been top of mind for us more recently to be transparent about our plans and update the tickets accordingly. Unfortunately, sometimes we have to postpone some things so that bigger and better initiatives can run, that is the nature of product management. I am happy to see that you are appreciative of these efforts
As for your tickets that you asked about:
- https://jira.atlassian.com/browse/JSDCLOUD-9439 we've got the right person assigned to this now, and this may actually be a bug as opposed to a feature request, so we should probably take a deeper look. I was assured this will be looked at in the coming week and we will provide the update on the ticket. Thanks for flagging.
- I will be getting an answer tomorrow about https://jira.atlassian.com/browse/JSDCLOUD-4354 . Stay tuned.
Thanks again!
Liron
Thanks greg.draper310998593 for your understanding of our difficult situation, trust me I wish I could put all these tickets in the roadmap...
As for the ones you asked about :
- https://jira.atlassian.com/browse/JSDCLOUD-2373 is in the roadmap , yep!
- https://jira.atlassian.com/browse/JSDCLOUD-3371 as well, will get an update tomorrow I believe
- https://jira.atlassian.com/browse/JSDCLOUD-4551 this one I'm not sure is on our radar, I'll have to spend more time understanding it. Are you available to chat about it to provide more context?
Thanks!
Liron
I commend your team for responding to the backlog of feature requests. In the past month, I've seen activity from Atlassian on this front and appreciate the action to some forgotten items.
This is not a deal breaker for me and I do realize that there are other means to get particiapants on a ticket submission via email (as a cc'd recipient) or post ticket creation in the customer portal. Although this feature would be nice to have, I definitely agree that it's not a priority and other submissions deserve more attention. To name a few:
- At the customer portal, users are able to submit a request before the attachment upload has been concluded - https://jira.atlassian.com/browse/JSDCLOUD-9439
- Increase Jira Service Desk email attachment size limit - https://jira.atlassian.com/browse/JSDCLOUD-4354
Liron, I do want to commend your transparency though. We should have more updates like this. We just wish that you all would fix the things that are big blockers in JSM and are actually beneficial to your customers. If you are going to implement these below three soon instead, I think that is the correct decision of priority, because these are much more important (no workarounds):
- Let comments go on any issues where someone responds to an email with the issue key in the subject line (feature has been in Server since 2017) - https://jira.atlassian.com/browse/JSDCLOUD-2373
- Remove the login auth required to view/download a non-image attachment from a JSM email (it is not needed as actual attachments in the email as the summary states, but same concept) - https://jira.atlassian.com/browse/JSDCLOUD-3371
- Let Service Desk Agent edit the display name of portal only customers in the Customers section in the project (again, summary is misleading) - https://jira.atlassian.com/browse/JSDCLOUD-4551
At least with the creating with request participants, someone can create, then share in the portal, or just email and CC people if you have that unlocked. I am not advocating against doing this work (there is room for all 4 things to get done right now). You still should let us add it to the create screen (for both internal and portal creation), but the above three are definitely more important.
Can just agree with the comments above.This is very frustrating.
Our team uses this feature heavily now that it's available for Jira Service Desk Server. To not have this in Cloud is a big step backwards and quite disappointing. It's these kinds of things that really keep us dragging our feet from moving to the Cloud. Sure, there might be more new things, but to have some features available in Server but not Cloud? That's a step backwards.
This is very frustrating. The ability to copy a user on ticket creation is a very basic requirement for a service desk.
Can just agree with the comments above, I don't understand the decision either. My team and I use the JSm only for communication with external customers.
This feature is crucial to use Jira Service Management with external clients/ users, how can we otherwise use the portal to reach out to multiple client contact persons when entering our communication in the issue description field?
Now we need to do it twice, once when creating the ticket and then again as a comment after adding the request participants, and the reporter receives two updates. My users have to do a lot of extra work and don't see the benefit of Jira Service Management so they switch back to emails which we wanted to phase out. I really don't understand your decision and this should be a very simple change.
Wow.. just wow... not being considered is a clap in the face... this just reinforces our decision to move to another system soon.
Hey Susan,
I agree that the decisions on what has been worked on for the last few years has been bad. Just figured I would let you know that you can still create that custom user "Share with" field in Cloud to do the copying at creation (if you were worried about that...wasn't sure if you were thinking you couldn't or just saying that it should be easy for Atlassian to implement this). It stinks that you would not be able to share with any random email address that way (the true power in Jira Service Management is for external customers and Atlassian needs to fix a few key pieces to keep their product in a good position in that space... hopefully they will realize that external is more important than the IT folks that already could do everything that was recently launched that now just comes packaged).
Liron,
I'm appalled at this decision. 389 votes? That's ridiculous that you can't put this on the roadmap. I'm on Server terrified to move to Cloud because of insanely short sighted decisions like this for the product. On my server version, I have created a user picker field that is on the create screen. I call it "share with". The create post function then copies that field to Request participants. Voila, done! How difficult is that really to implement? And that you made Jira extensions by Deviniti remove this functionality is even worse.
How in the world did you become the JSM product manager after your insane, short sighted decision to remove page trees off the space view on confluence cloud 18 months ago, that caused the biggest uproar on Atlassian community and that was eventually reversed after much pain and public outcry. My users suffered badly from that decision for many months before it was reversed.
Please, please reconsider this decision. I have been using Jira for 12 years, a true expert and an Atlassian community leader for events for 6 years. I know the features that users really, really want, and this is definitely one of the.
Susan
Hello everyone,
We appreciate the merit of this issue, but wanted to update you all that at this point in time, it is not on our roadmap in the foreseeable future. The solution here is not as straight forward as we would have liked and we are intending to bring many other improvements to the product that are at this point prioritised higher than this one.
We will be reviewing this again within 6-12 months and will continue to update on this ticket, so stay tuned.
Thanks again,
Liron Deutsch
Product Manager, Jira Service Management
96677a1d9b4c , wouldn't it be appropriate to update us on this topic (more than 6months later)...?