This feature is definitely needed and I can see that a workaround has been issued which really isnt the answer. see link below:

https://community.atlassian.com/t5/Jira-Service-Management/Can-a-customer-create-a-request-on-behalf-of-another-customer/qaq-p/948398

Is there a usergroup where we can raise issues like this or how do we escalate to Senior managers in Atlassian? I'm surprised that this ticket was raised 8 years ago!

This is an essential feature for allowing clients and their third parties, like SEO companies, to raise tickets on behalf of one another where necessary. If an SEO expert works with multiple clients of ours, they have to be sure of raising tickets for the correct company. It's too easy for a user in multiple organisations to select the wrong one or omit it altogether. If they have to search for the email of another user in their organisation, they're less likely to make a mistake and we can more easily find those tickets.

@benjamin

I come to your same conclusion but I could not make it working. If you can explain the steps in how you achieved that, it would be much appreciated.

M

addendum: I did solve it . . . I needed a coffee break

We would also like to have this possible, so vote from me

Also voting for this one.

This is huge for us, for managers opening on behalf of their employees, for employees opening on behalf of their managers, for key users of certain applications that all of a sudden we need a license for, just so they can raise tickets on behalf of the standard user that has the problem...

And no, adding them as "watchers" is NOT a solution - the actual, relevant notifications would still also arrive to the original opener, and there could be GDPR implications as well due to data privacy (HR also uses our Jira instance).

what about to enclose a form to the request with some user picker field which normally cannot be added to the screen on portal? Doing the same for version picker field and similar types not allowed on portal. You just map the "form" field to Jira field on backend and it works perfectly even for priority and such...

I am voting for this feature considering that we are using a lot of automation with assigning assets to INsight. 

Would like to see this.  Same reasons as mentioned above.  Need admin staff to be able to open tickets on behalf of other users.

I would also echo this request and add my vote in favor of this capability for our customers.

I second what Sue said.  We are in the same situation.  We must have the ability for our teams to raise the request on behalf of an executive or another team member.  But these team members do not need to be inside of Jira - they only need to be customers.  It's sad that I'll have to ask my executives for more money to pay for licenses for "customers" that might never even have to raise a request.  But they need a license to have the "on behalf of" option if ever comes the time.

When is this planned for development??

With Insight, we are unable to create automation using the custom fields we are creating for users*. We can, however, use the reporter field. We are finding, very often, the the reporter is making requests for someone else (we use a Jira custom field for "affected user").
"Raise this request on behalf of", would allow us to create the automations needed for approvals that are made on behalf of someone else.
*Edit - we did figure out how to use automation with the custom insight field we setup for users.  We needed to be able to allow someone to enter a ticket for someone else, but make sure that the person they entered it for would see the ticket notifications.  The automation shares the ticket with the person they entered the ticket for.

Hi Ben,

Thanks for the suggestion. We have done the same thing with a client with this requirement, although we selected to copy the value of the user picker into Request Participants rather than reporter as there was no way to control who had the ability to see this field. (In other tools, there are capabilities to limiting this down to groups / roles -.e.g. Managers, Execs and Exec Assistances).

The feedback we received was that this quickly became confusing for Agents, who now had 2 'Raise on Behalf of' fields present on the request types. 

Thanks for the feedback folks.

A possible workaround here could be using automation. I tested it out just now. 

1. Create a custom field of type user picker for your Delegate
2. Create an automation rule that triggers on creation, checks if a value is set for the Delegate field
3. If it's not empty it updates the Reporter to the Delegate, and then optionally sets the old Reporter to be a Request Participant.

This will allow you to achieve the outcome you want, but also will maintain an audit trail in that you can see who actually raised the issue (to avoid anything suss happening).

Let me know what you think.

Cheers, 

Ben.

Another example of this in practice is for executives, who often have their executive assistance create requests on their behalf. 

This is something that other ITSM tools are able to cater for, where as the best we can do is to use request participant field, and then modify the reporter as part of the manual triage process.

Hello Benjamin.

I'm glad to see the JSM team interested in this feature. In addition to automation capabilities described by Sam C and potentially others, this feature would be very helpful in scenarios where colleagues assist each other with making requests. The colleague assisting isn't the Reporter (customer), they're just a 3rd party putting in the request on behalf of someone else (e.g. the customer is on the road or otherwise unable to submit a request but are able to call in or mention in passing to someone that is able).

Hi Ben,

For us, we have automation tied to the Reporter field to pull the user details into the ticket from our external directory (because there's no way to configure custom properties in Cloud for provisioning) and to add groups to their directory account for some access requests.

We use the Reporter field as the user affected / needing support, which is not always the user logging the ticket.
Reporter is also used for Reporting and Analytics.

Having the Raise request on behalf of feature available for customers in Portal would allow more seamless and faster support when a customer is logging a request on behalf of another customer.

For us, the customer that logged the request on behalf of somebody else usually doesn't want ticket updates, these should only go to the customer affected  /supporting. If the creator wants updates, we can add them to Request participants but this isn't so common.

Thanks for your support,
Sam

Hello all, 

I am a Product Manager on the JSM team. I am eager to understand more about this request. 

How would this feature be different to the request participants feature today? Is it about automations associated with the reporter field? If so what type of automations are you using?

Let me know how it would help you.

Ben.

The video attachment by @Simon Bradford is exactly what we're needing

https://jira.atlassian.com/secure/attachment/413232/Raise%20on%20Behalf%20Of.mp4

That's a basic need especially when you are working with automation and Executive assistant

They can't raise ticket on behalf of the Exec, it doesn't give a good image of JSM to the board of direction.

Wow Jira - A simple thing here.  How are users who's PC's are inoperable supposed to lean on their peers to assist in opening a ticket to engage support.  This is a pretty basic function of EVERY HelpDesk/Service Desk software I've ever used.  

As mentioned, this is a HUGE gap in Jira Service Management... HUGE

This is crazy to not have as an option. I would say my biggest disappointment coming from Jira Server to JSM is the rigidity. There are quite a few things you just can't do that seem very basic...

How is this NOT a current feature already?  This is Service Management 101.  Some simple, every day scenarios that warrant this feature:

1.  Employee A's computer is down.  Turns to Employee B and asks them to log a ticket for them.
2.  Any situation where you have an executive with administrative assistants
3.  High Profile/Output staff who have a dedicated support person for a group

yes, I know you can change it, but the concept of this software is to make it agile and lean, and making me change things every ticket is counterproductive.

This is a HUGE need for many organizations!

I agree, the manager opening on behalf of their direct reports and consultants/contract help is a common occurrence for us as well.

It is very common, where I work, to have one customer enter a request on behalf of another customer.  E.g. A manager (who really has no need to be a Service Desk Agent), enters access requests for their employees or contractors.  We've had this in the tools we've used over the last decade , or so.  

I'm not sure I understand why it wouldn't be standard, other than the fact that we'd have to pay more money to allow more people the permission.