Advice request: Moving from inbox to JSM, the team wants to disable external notifications

Question

Hi there,

We have a team moving from a shared mail inbox into a JSM project, and I have a few concerns about how things will work, so if anyone has advice, or has gone through a similar scenario, I'd love to hear what solutions you used, specifically around handling external inbound mail and ticket creation, notifications sent to externals etc.

I am the Atlassian admin for the org, so please do share technical solutions or ideas as well.

The intention would be to use the same email address that they currently use as the email channel for the JSM project, but the way the email address is used creates some challenges.

Here are some of the ways that externals are interacted with currently, that would need to continue to work in some fashion once the team has a JSM queue:

* Shared Inbox CC'd in on an external outbound email
* Shared Inbox BCC'd in on an external outbound email
* External periodically emails the inbox directly
* Inbox sends outbound mail to externals

And this is of course made more complex by customer permission settings. We currently allow externals to create their own portal-only accounts, but we have a set list of domains that are allowed.

Given the nature of this team, externals would be our clients, so there is no one domain that we can allow account self-creation for.

I'm left with solutions that involve some element of continuing to work out of the inbox.

Perhaps the solution is a new designated email address for this team, and when staff email the 'old' address, behavioral change is encouraged?

Any ideas, similar solutions or scenarios, greatly appreciated.

Thank you!
Eli

Jack Brickey · Answer

Yes... I think you have it. The key take away here is that if external clients are not to be aware of anything about the actual existence of a ticket then they should not be CCed on the email used to create or comment on an issue in JSM. One caveat to mention, though, JSM supports both internal and public comments. So customers will only see comments that are specifically made public. But again if the external client does not need to track an issue then in reality I'm not sure JSM is the right app here unless you are using it for internal customers.

Eli Devlin · Answer

@Jack Brickey That's right, the agents are a non-IT team who have used a shared email inbox to support their customers (internal staff) and are now looking to move into a JSM project with associated email and portal customer channels, to replace the email inbox as a work management tool.

I think you've hit the nail on the head here: a new, dedicated email address for the project's email channel.

The concerns the team had were all around how the email address is currently used by customers, e.g. a customer (our internal staff) will email an external client, and as an advisory they will BCC the agent team into the email chain. The concern would be tickets being created under external client names, notifications being generated to external clients - generally, confusing notifications for external clients (we are in financial services) so this was extremely undesired.

With all that in mind, the only practical solution is a new email address I suppose. It would be used for internal issue generation.

Thanks for bearing with me here Jack, it's a convoluted question

Jack Brickey · Answer

@Eli Devlin ,

I am not yet following. I don't understand what "moving from inbox to JSM" means. Are you saying that you have agents that have historically supported customers via email now moving to JSM? Further, are you saying that these agents have indicated the customers (reporter) should not be notified of updates to the issues they raise?

I am sure I am missing something here. One thing I highly suggest is that you create a dedicated (not used for other purposes) email for the support project. Regarding customer notifications these are configurable under project settings > customer notifications. But I suspect you are already aware of this.