nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Email ingestion to a JSM space is not working consistently

Shaun McGuire

I set up an email channel in a standard JSM space.

Full setup/workflow is thus:

Email sent to a shared email box (sharedbox@abc.com)
Mailflow rules in Exchange prepend a prefix to the email subject line "[XYZ] " then redirects the email to the wrkhubagent@abc.com account (which is the one I have set up as the email channel into the JSM space) and also redirects a copy into the original shared email box

The mailflow rule works perfectly, and the email ends up in both boxes as expected every time, no matter who sends the email

But the ingestion into the JSM space only seems to work for me and my counter part internally. Anyone else internally that sends an email to the shared email box, the mail flow rule prepends the prefix and redirects, but then NOTHING happens in the JSM space at all. No errors reported, nothing.

How do I troubleshoot this?

Accepted answers

All comments

Marc -Devoteam-

Hi @Shaun McGuire

Are these user added in the rile service desk customer or are they customers already.

How are the customer permissions setup, restricted or open and the global customer permissions.

To have unknow users email and an issue needs to be created, the users should already be added as customer or added in the people section with the role service desk customer.

If this means that this is admin work and not wanted, then the permissions of the JSM space should be set to open.

Jack Brickey

I have to wonder if this is related to using a shared mailbox. It would be interesting to try to replicate with a non-shared email.

Shaun McGuire

These are internal employees with Jira accounts already.

I do see these errors in the View Logs (just found that). The one that worked was sent from me. the rest are all fellow employees

They are NOT nor will they EVER be JSM agents. Furthermore, I specifically setup a service account (wrkhubagent@) to be the source email account.

I do eventually need this to work for external users (unknown who) to send email to the shared email box and then this process takes over and moves it through.

Shaun McGuire

The service account (wrkhubagent@) is NOT a shared email box. It's a full user M365 account. That's why I have the mailflow rules that take what was sent to the shared email box and redirect a copy to the service agent account for ingestion

Jack Brickey

You should report to Atlassian Support for investigation. As a premium account you should get a Buick response hopefully.

Jack Brickey

If you do, please share findings here. Thanks!🙏🏼

Shaun McGuire

I found where I went wrong. thank you for leading me in the right direction:

I had Customer Permissions set to restricted. I've since changed it. Hopefully this will fix the issue

Shaun McGuire

It's so often a little thing you miss when moving at lightning speed.

Shaun McGuire

I had to correctly configure Customer Permissions as well. Leave it to Atlassian to put required permissions in multiple places. All is well. Thank you all for the help.

Marc -Devoteam-

Hi @Shaun McGuire

I any of our answered helped you, please accept it as answer.

This will help others on the community as well.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-service-management-cloud

jira-service-management