Jira Service Management (formerly Jira Service Desk) includes a nifty feature that allows an agent to create a request on behalf of someone else. It is certainly well suited for those side conversations happening via text, IM, phone (maybe not so much at the water cooler these days). But you get what I mean. This little ditty helps agents keep work from getting lost in the shuffle and customers from feeling like they got the brush-off when asked to submit a ticket. A win-win, really.
"Raise this request on behalf of" appears right at the top of the screen on every request form in the portal, that is unless you're not an agent. "Why should they get to be so stingy with all the on-behalf-of love?" you might ask. "What about those times when non-agents would like to submit a request on behalf of someone else?" I don't blame you for asking these questions. Why? Because you're likely a Jira administrator looking to solve some flavor of the use case where a VP or Director, for example, is expected to NOT submit issues directly in the service desk portal, and instead an administrative assistant or other colleague does so on their behalf.
You may also be wondering where this whole "let-me-submit-for-other-people" business is on Atlassian's radar. Well, it is, in fact, in their JSM backlog. Although with less than 100 votes, who knows when Atlassian will consider it for prime time. If you're still game for the feature and don't want to wait for Atlassian or hunt around for a niche marketplace app, well then, your Google search and sleuthing has landed you in the right place for some healthy inspiration and clarity to get you going.
Before you comb through all these detailed terms for your late-night reading pleasure, know this first: I documented and later modified these terms as the result of an actual "Customer creates a request for someone else" implementation that happened to integrate with Insight Asset Management. This integration allowed for JSM and Insight to serve up dynamic details exposed directly in the request. This prevented agents from having to troll through several internal systems to get all the information they needed to service the request properly. Things like the requestor's office location, security clearance level, direct manager, phone number, etc., were right at their pretty little fingertips. Pretty cool, right?
I say all that to tell you this: Insight Custom Fields and some SIL scripting were used to carry out the automation noted below. Yeah, they were the proverbial meat and potatoes in this solution. Don't have Insight Asset Management and still could use a solution? Don't worry. You can use the automation magic wand of your choice, like Automation for Jira or Power Scripts, and you should be just fine.
I also found out the hard way that if I didn't clarify some basic terminology up front, discussing this functionality and its implementation got way confusing, way quick. Yes, those are technical terms—words way matter.
This approach assumes that the people all have an account on the Jira site. If you're in the camp where your third person, for example, will not have an account on the site, you may just as well train your customers to include the third person's name in the description or comment on the request and leave it at that.
|
Person |
Description |
Notes |
|---|---|---|
| Agent | Licensed Jira Service Management team member who monitors/works/responds/slays incoming requests/issues/whiners. | JSM license required |
| Customer | A person who requests support from the Jira Service Management team. |
has an account on the Jira site |
|
Third Person |
A person who may or may not have the ability to directly request support from the Jira Service Management team, but who is involved with the request or should be the recipient of the outcome/resolution of the request. |
has an account on the Jira site |
People are different than the fields where their names end up in Jira. For example, there is no "Customer" field per se, even though in general, Customers create requests in JSM. Again, talking about people without distinguishing which field you're referring to, can make for madness. For example, the reporter field in JSM is actually labeled as the Requester in the portal.
|
Jira Field |
The Person Who... |
Field Notes |
Notes |
|---|---|---|---|
| Creator | The person/user who created the request. | This is a Jira system field | This field is not visible on requests or issues, but can be seen via JQL search results and the values are actually the same as the reporter field. |
| Reporter | The person/customer who contacted support with a request. | This is a Jira system field. | This person is shown as the creator from the portal. In the "my requests" section of the portal, this person is listed as the Requester. |
| Contact | The person who is the recipient of the request's resolution. | This is a custom field. | The name of this field can be whatever works for your organization. Bonus points for you Insight customers as this can be an Insight custom field that automatically displays their contact information, i.e. work location, assigned equipment, access levels, phone number, manager, etc. |
| Request Participants | The person(s) who can view, comment, and receive notifications about the request. | This is a Jira system field. |
In addition to the requests a person has created (or rather where they are the Reporter), they can also see shared requests from within the portal. Specifically, "Where I am a Participant," or that are "Shared with my Organization(s)". |
The solution really comes down to a custom field and some automation, however depending on how complex you want to get or how exactly you may adjust these scenarios for your use-case, this table (or one like it) will certainly come in handy. Knock yourself out.
|
Scenario |
Assumptions |
Creator |
Reporter |
Contact |
Participant |
Automation |
|---|---|---|---|---|---|---|
|
1. Customer submits a request for themselves |
The contact field on the portal request form will be null when the customer creates the request. |
Customer |
Customer |
Customer |
|
|
|
2. Customer submits a request for someone else |
The customer will populate the contact field on the portal request form with the 3rd person. |
Customer |
Customer |
3rd Person |
3rd Person |
|
|
3. Agent submits a request for someone else |
The agent will populate the Raise a request on behalf of field with the customer. |
Agent |
Customer |
Customer |
|
|
|
4. Agent submits a request for a customer who is wants to submit a request for a 3rd person |
The agent will populate the Raise a request on behalf of field with the customer. The agent will populate the contact field with the 3rd person. |
Agent |
Customer
|
3rd Person |
3rd Person |
|