Identify requests created on behalf of reporter

 

Platform Notice: Cloud - This article applies to Atlassian products on the cloud platform.

 

The guidance provided in this article is tailored towards Jira Service Management, however other Jira products such as Software and Work Management also have the ability to raise requests on behalf of other users and the information contained here may be relevant to use cases involving those types of projects.

Summary

Roles such as project Administrators and Service Desk Team members are able to create requests (issues) on behalf of other users by toggling the user in a field labeled as Raise this request on behalf of. This is essentially the Reporter field that is otherwise visible on the Issue View once a ticket is created. Specific details on how to raise a request on behalf of a customer can be found on the support article titled Raise a request on behalf of a customer. This article intends to provide methods to flag that the ticket was created by a user on behalf of another user or to adjust fields that rely on a given reporter.

Identifying tickets created on behalf of a user

Jira has a separate internal identifier for an issue's creator and reporter however the value for the issue creator does not have a specific field unlike the Reporter custom field. While there is no specific field to call, the Issue History will have a record to the user who created the issue, which may differ to the user that is set in the Reporter field as demonstrated below:

it's worth noting that an issue may display a different reporter and creator when viewing the issue history if the reporter was changed on the request after it was created. In those cases it should be evident as the issue history will have a user that is different to the creator listed as the original value of the reporter field:

Scenarios

Adding a comment to issues raised on behalf of someone else

In certain cases for ease of auditing, adding an internal comment for issues raised on behalf of another user are helpful. This can be achieved using Jira's Automations by comparing the creator value with the value of the reporter at the time of issue creation. While the data for the issue creator is not stored in a custom field, automations Issue fields condition can be used to check. The following automation rule compares the value of Creator with Reporter and if they do not match, it adds an internal comment to the ticket.

The above rule is a high level proof of concept and should be tailored to your needs by adding additional conditions such as providing parameters on which issues to execute on. The internal comment uses the display names of the creator and reporter and the text can be customized to your needs:

This issue was raised by {{creator.displayName}} on behalf of {{reporter.displayName}}.

The result of the above automation rule is shown below:

Track the request creator through a custom field

While the issue history tracks the issue creator, there may be cases where for reporting purposes or additional data aggregation it would be beneficial to have the creator recorded in a custom field. Either a user picker field or a text field can be used to record data about the creator, however it's worth noting that these fields can be edited via the issue rule. An option may be to utilize a Text Field (read only) type field, which will prevent edits being made via the issue view. It's worth noting that this field can still be edited by other automation rules therefore using the issue history would be recommended for definitive audit purposes.

This section assumes that a custom field has already been created and configured with the issue type and request type already. Guidance on creating custom fields can be found at the Create a custom field documentation. In the example below we are using a Text Field (read only) and will be re-using the automation rule configured in the step above. The addition to the rule will be an Edit issue action, which will use the {{creator.displayName}}  and {{creator.emailAddress}}  smart values to capture the data, since we are using a text field. if using a user picker field, {{creator}} will work to set the user:

The result of the above rule is noted below:

Filter Assets custom field data based on the reporter

While not so much a case of identifying issues having been created on behalf of another user, this scenario can help restrict data that can be chosen at the time of issue creation in cases where data such as the reporter's supervisor or manager may be different to that of the person raising the issue. In those cases if this data is contained in Assets, filtering can be added to ensure only relevant Assets data is returned when the reporter is changed.

As noted earlier on this article, the field Raise this request on behalf of is the Reporter field. Assets custom fields can be filtered based on certain system fields as described in the support documentation Configure the Assets objects custom field. Using the placeholder ${reporter}, the Objects a field returns can be restricted. Changing the user will change the Objects that are returned.

In this scenario, it is assumed that a User type attribute is used on the given Object and that this attribute is configured with the user that is being selected. An example Assets Schema to demonstrate this is below:

In this scenario we are using an Assets custom field called Impacted User which has the following configuration:

The highlighted portion is where the filtering happens. Using the Filter issue scope (AQL) data, we can reference the User attribute seen in our earlier screenshot to only return the Objects that the user set in the reporter field is associated with. The AQL in question is:

User = ${reporter}

In this case, changing the user to Test user returns the object that this user is associated with:

If the user is selected is not configured with an Assets Object, no results will be returned. If that field is marked as required, this will prevent the issue from being created, therefore when configuring this setup ensure that potential users are associated with an Object or do not mark the field as required. In case a user is associated with multiple Objects, each Object will be returned as a possible selection.

Last modified on Nov 16, 2023

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.