96677a1d9b4c , wouldn't it be appropriate to update us on this topic (more than 6months later)...?

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. 

I Hate Atlassian

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.

I didn't expect that this is not already possible.

Should the status of this issue be changed?

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

Another Jira Cloud limitation we did not have in Server & Data Center

Atlassian is a fckin' ridiculous company. Pathetic.

yes, will be good to have this basic feature

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.

VERY frustrating that this is not possible!!!

Very Disappointed to hear this.

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?

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.

+1 Would make our outgoing client communication much smoother.

Its a shame that this isn't implemented yet.

+1 required, needed, mandatory item

+1 Really needed.

Please reconsider

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

+1, seems like a no brainer...

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:

https://webcache.googleusercontent.com/search?q=cache:npgZs8l91MYJ:https://ja.confluence.atlassian.com/jirakb/how-to-add-watchers-or-request-participants-during-issue-creation-975018319.html&cd=1&hl=en&ct=clnk&gl=us&client=firefox-b-1-d

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?

Please add this feature!

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.

+1

Please prioritize this request.