Multiple projects and emails

[SP]

We use JSM Data Center on-prem, and we're using JEMH as our mail handler (because we needed to process incoming emails from a drop a folder).  We have 4 separate projects set up in JSM for basically 4 different service centers in our organization (this is all internal to our own employees), and have more on the way.  The challenge we have is that sometimes user requests need to go to more than one service center and sometimes users forward emails around or take responses from one service center and send them to another one, expecting action to be taken.

The first challenge is that an email that is addressed to two different projects only ends up creating an issue in one of the projects.  JEMH support sent us a script that could be added to the mail handlers and could, perhaps, be used to address this.  But at first glance it is a clunky and inelegant solution.

The other challenge is that users forward emails around.  For example, an issue is opened with service center A, and an agent sends the user an email from the system.  The user then takes this email, which has the issue ID of the open issue in project A associated with it, and forwards it to the email address for service center B.  The expectation is that a new issue would be opened in project B.  But instead, the email is added as a comment to the original issue in project A, and the agents in service center B have no idea anything even happened.  Or an email thread involving service center A is forwarded to service center B.  Now thread detection in JEMH is still tying that email back to the issue that was opened in project A when the first email was processed (because of the message ID), even though the new forwarded email was addressed to service center B only.

I'm curious to know if other people have run into the same challenges and how they've solved them?  Is there a different mail handler we should be considering, or a more elegant way to handle this?

[Finn Gale]

Hi SP,

Finn from JEMH Support here. As you mentioned you've raised a ticket with us but we haven't heard anything back. We're happy to continue the conversation on our existing ticket if you'd like to look at other approaches to this scenario.

- https://thepluginpeople.atlassian.net/servicedesk/customer/portal/1/SUPPORT-11096

Whilst JEMH's Script Field Processor can be used to create multiple tickets from a single email, for ease of customer use we would recommend centralising interactions, to reduce duplication and overloading responses to the customer. As an example, if a customer included three Catch Addresses, then three new tickets would be created, sending three 'Issue Created' Notifications back to the customer. The customer would then have to manage three email threads to multiple teams.

Perhaps a simpler solution for the customer would be to tie multiple teams to a single issue so agents for B, and C could interact with the customer on Project A, limiting customer interaction to a single mail thread, and keeping all relevant parties informed of issue progress. Let me know what you think.

All the best, Finn.

[SP]

Thanks Finn.  We're certainly going to continue working with your support team on this.  My goal in posting here was to solicit feedback from the broader Atlassian community.

The service centers deal with different types of requests and are in different departments in the organization.  We also can't allow the agents access to issues in other projects for security reasons.  If a user is sending an email to A and B, the most likely scenario is that they're expecting the agents in A and B to perform different, if somewhat related, tasks, and would expect two separate responses to the different requests made.  And when they take a response from A and forward it to B, they are doing so quite intentionally, because they need the agents in B to perform an action that agents in A can't, and sometimes shouldn't even know about.

[Finn Gale]

Appreciate the clarification. We've had a discussion internally on possible approaches to a 'cleaner' solution, and how we might implement them. For the time being the best approach will be to use a Script Field Processor as we previously mentioned. 

We will provide more info in the open support ticket.

[Nic Brough -Adaptavist-]

Welcome to the Atlassian Community!

Most of your problems are probably human problems, not problems with the software, and they don't really have technical fixes

>The first challenge is that an email that is addressed to two different projects only ends up creating an issue in one of the projects.

How are you "addressing an email to a project"?

>The user then takes this email, which has the issue ID of the open issue in project A associated with it, and forwards it to the email address for service center B.  The expectation is that a new issue would be opened in project B. 

Why would you expect that?  The email is clearly a response to the issue in project A, so that's where it should go.  All you can do with that is turn off the "comment" functionality, so that emails going to B all create new issues, no matter whether they refer to other issues elsewhere.

I'm afraid the only real fix for this is to get your humans to stop misusing email.  There's also the question of why they are emailing a second project when they should really be working together on the same issue.

[SP]

The humans aren't going to change their behavior, and it's unreasonable for us to expect them to -- they're the customers and we're trying to serve them with the least amount of work on their part.  So we need to come up with a technical solution.

I should add that we are not using the self-service portal.  People are either emailing their requests in or calling them in by phone.  This is very much intentional.

How are people addressing an email to a project?  They send an email to a specific email address, which causes that message to be sent to the Jira server and placed in a file folder. JEMH has mappings for catch email addresses to projects to then create issues from these incoming emails.

[Nic Brough -Adaptavist-]

I'm afraid that's not an option.  Whatever you do about this,  some of your humans will need to stop their broken behaviours.

You have a lot of options, including these basic ones (which you might adopt more than one of)

• Educating the people raising the issues
• Come up with some way of identifying when the users are doing the wrong thing, and work out how to correct their errors.
• Turn off the ability to comment via email, so the emails always create in the right project.  (This will have the advantage of forcing them to use the portal to inteact with their existing issues, which is generally easier than using email anyway)
• Redesign your helpdesk - why are issues being raised twice in two different portals?  Surely they should be in the same place?

[SP]

Nic, I appreciate the feedback, but I fear we're not on the same page at all.  We're not supporting a single help desk.  We're supporting a number of different service centers, only one of which is the more "traditional" IT help desk.  The agents in different service centers can NOT have access to each other's projects and issues.  And training the user population not to do the "wrong" thing isn't feasible in our situation.  Turning off the ability to comment by email is also not feasible -- that's one of the most critical features of the system.

[Nic Brough -Adaptavist-]

I understand that, but it doesn't change the answers - your structure is wrong (sending the same mail to more than one helpdesk yells that there's something wrong with the structure), or your people are doing the wrong thing (why? Have you set up your helpdesk in a way that requires split working or confuses the requestors?), or you've fallen back on email because your managers have said "we only want to use email" despite the portals being a better way to work, or your agents are unnecessarily siloed because your entire organisation is stuck in the past?  Or a combination of varying levels of those things?

Anyway, if you can't face changing bad behaviours, processes, or structures, then your only option becomes complex coding and config.

I'd strongly recommend doing what you are already doing - engage with @Finn Gale - JEMH is very clever and can probably deal with most of your users doing klunky things.  I still doubt it can do everything you might need, and you will still have to "educate" some of your users, but I think you can get close with it.