Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Workarounds for Certain Tickets to Have Reporter Based on Root Email?

Calvin
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
November 23, 2023

Hi all, many products will take the root email as the reporter of the ticket instead of the sender. Which can be useful for times when items are being forwarded. For example when a system emails a user who then forwards to the Jira Service Management. And you want the system as the reporter for analytics.

While I understand from searching this isn't the way in JSM (and makes sense in many cases to why not). We do have an instance where a user will send an email about a certain case to another user who then forward to the Service Management. Where we still want the original sender to be the "Reporter" (not previously a customer in JSM).

I'm hoping to find an easier way to implement this, I know the type of ticket based on the text in the subject line so i can pick it up by Automation. But how do I grab the original email address and make it a reporter?

I've looked at getting the forwarder to CC the original person, they're not a fan but at least it creates them as a customer. I still need a manual automation though to move the request participant to the reporter as the "Create" trigger seems to find the "Request Participants" as empty at that time.

I also don't think there is any other way around the reporter part without having to create them as a customer section first (which might be too much for the forwarder to do). But if you know an option, that would be great so the original sender doesn't see the forwarder email.

Am I just overthinking this? Thanks for any advice.

 

1 answer

1 accepted

1 vote
Answer accepted
Walter Buggenhout
Community Champion
November 25, 2023

Hi @Calvin,

Very interesting use case. I am afraid you may be overthinking it indeed - expressing my honest opinion there. 

If I understand your use case correctly, you are letting people send an email to a mailbox that is not connected to your service portal. Someone then reviews that mailbox, and when he/she decides this email should become a ticket, then forwards the email to another email address that is connected to JSM to convert the email into a ticket? That would then lead to a situation where you would need to build a complex automation to somehow work out the original sender to the disconnected email address ...

Let's assume for a second that people are using the disconnected mail address for a lot of things that shouldn't be ticket in JSM. That would make it a legitimate use case to keep that mailbox alive, obviously. But if the reviewer finds something that is worth converting into a ticket, why don't you reply to the original sender to either forward the message to the connected mailbox instead? Or even create a ticket in the portal? That would eliminate your sender/reporter problem and increase engagement with your service desk.

Hope this helps!

Calvin
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
November 27, 2023

Thanks Walter, you understand it perfectly :).

why don't you reply to the original sender to either forward the message to the connected mailbox instead? Or even create a ticket in the portal?

I think herein lies the issue, the people who own that area wants users to come to them first, but then create the ticket afterwards without having to add the user into the customers section or create their account as there can be many new users.

They also don't want to let each new user feel like they have got to re-do it or re-send it.

But I do feel you're right end of the day, and I think thats really how JSM is developed so maybe we need to discuss more if the portal/direct may be the better way to implement.

Cheers heaps.

Like Walter Buggenhout likes this

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events