We have transitioned a legacy email group-based service infrastructure to Jira Service Management. Because we have been using the same service email address for the past three decades, we are using the email channel to ease the transition for our users.
We have added the channel's Atlassian email address as a member of the legacy email address and removed our agents therefrom, instructing them to use the Jira Service Management project instead.
This works mostly fine, but a large portion of issues created via the email channel incorrectly set the Reporter to the receiver's email address instead of the sender's email address. This means the customer (original sender) cannot see any responses until we update the Reporter field manually.
As a workaround, we currently have an Automation Rule that detects when the Reporter is set to the receiver address and notifies our agents to manually correct it. The correct sender is usually listed as a Request Participant, but sometimes our Agents need to log into the email group to see who the original sender actually was.
We have not figured out a way to reliably reproduce this issue. I have audited our Google Workspace email logs to see if there is any difference in the configuration of emails that work properly from those that work improperly, but I have noticed anything.
With a configuration like this, there is some variability that can happen based on who the sender is, and how the message was sent (e.g. forwarding).
Rather than including the Atlassian email address in your email group, have you tried setting your project up to read directly from your email inbox? This is our recommended approach for interfacing with an existing mailbox.
You can configure this from Project admin > Email requests.
I hope this helps,
We hadn't noticed an option to use OAuth to grant access to the inbox when we looked, and our security policy prevented us from using the authentication method Jira Service Desk required. But this was to create a new inbox and add to the existing group.
If OAuth is supported, and direct access to our inbox will definitely solve our problems, we could consider it. It will be tricky to convert the existing address from a group to an account without causing downtime. It would be pretty frustrating if doing this didn't solve our problem. The group currently allows our agents to view the original emails outside of Jira when bugs like this one occur.
I would be a lot more comfortable if I understood the underlying cause of this issue. I would think it would only have to do with the email headers.
Yes, OAuth is support for GSuite and O365, with OAuth 2.0 support coming shortly.
Alternatively you can use IMAP or POP3 to connect to custom inboxes, although the latter should be a last resort.
This is the recommended approach, and should resolve the issues you are having. Without having hands on your instance and logs its hard to know exactly what is happening, but I have seen other customer cases with groups and forwarding running into the same trouble you are experiencing.
Maybe you could setup a new project with a test account to give yourself some piece of mind before making the change.
Sorry I missed your reply here. This very well could be the source of your problem.
We are looking into supporting multiple inboxes, which might help with your forwarding issue (e.g. linking multiple addresses).
But the forwarding should not be as big of a problem if an inbox connected.
I am interested to see how you go.
On October 20, 2021, Atlassian published a security advisory for Jira Service Management. The full advisory is available at this link. We've seen a number of questions already asking for...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events