jira as pure email helpdesk ? (no account setup)

[ipguy]

Hi all

I'm interested in setting up Jira as a "email only" helpdesk.

I'm not interested in having user accounts setup when someone emails the support/helpdesk address.

Is this possible ?

[Svante Jacobsen · Accepted solution]

We use Jira (4.2.4 10$) as an "email only" helpdesk. Users post tickets by mailing directly to our Jira-address. Users do get created in Jira but do not count towards the license limit thanks to the JEMH plugin (configured to add new users to our support-anonymous group instead of jira-users).

[James Sandlin]

After a lot of work, I found how we could have user accounts created and not taking a slice of the license. However, this led to the user not being able to interact with the ticket system via email as a user must have a license to post to a ticket.

Final solution: We implemented ZenDesk, which integrates beautifully with JIRA. It is a true help desk tool which is simple, elegant, and affordable. I would strongly recommend ZenDesk with JIRA integration to anyone who needs to provide app support tickets to an endless number of customers.

[James Sandlin]

Ivar: The issue is not spam. The issue is licensing. My company cannot afford an unlimited license count and with thousands of users and an account for every email submitting a ticket this is not realistic.

[Andy Brook [Plugin People]]

If the issue is licensing/cost, understand that you can create users in JIRA that do not have the right to use (interactively).

That subtle difference allows interactions by email, if configured appropriately. If you dont want to support _any_ user create at all (taking JIRA seats or not), then you have to add coding around inbound email driven issue creation, eg, mapping user emails to a custom field for onward processing.

I would say that using the existing notification scheme support is best, however, as I pointed out originally, this means there will be references to your site (unless you change the templates to remove them).

Just a thought, but if 'user count' is also an issue, it should be doable to come up with a way to remove them once some state is reached (eg custom field marked archive, issue is deleted entirely so user has no related reporter issues etc). Interested on thoughts...

[Ivar]

I wasn't really talking about spam. I was more talking about the fact that 1 single Jira user is actually used for X number of users. And these X number of users is only differentiated from each other on 1 custom field.

The solution mentioned by @Andy seems interesting though. Combine this with one of the plugins for e-mail and you might have what you need.

[Andy Brook [Plugin People]]

Since the question is not marked answered yet, I feel I can update it, as JEMH now includes the required missing functionality IMO to make JIRA viable for Helpdesk usage without creating users. The new functionality is an integrated IssueEvent listener, coupled with per-project customisable templates to 'tweak' content that the non jira-user receives, open for comments on how this works for people!

I would suggest that this is 'an' answer? :)

[James Sandlin]

My final solution: I implemented ZenDesk for our helpdesk system & integrated it with JIRA OnDemand. When our Help Desk group finds a support ticket they see fit to submit to development, they use the integration to create a JIRA ticket which is integrated with the ZenDesk ticket. This works perfect and it prevents us from using a process / defect system (JIRA) as a solution for our Help Desk. Instead, we have a true Help Desk tool which the group loves to use.

[ThorbjørnS]

But not for JIRA Ondemand, right Andy? Any news on when/if that will be available? We recently setup zendesk, but it would be even better to just use JIRA and not need to rely on two different tools.

[Andy Brook [Plugin People]]

Correct, I have yet to get to OnDemand, its very different, requiring a HUGE H U G E ! effort to implement.

There may well be lots of users OnDemand, but are they users that want a helpdesk solution, and likely, given they are sacrificing features for $, they will not be wanting to part with $. I'm not yet convinced.

I'd surely love to implement a remote plugin container, implement a Saas licensing model (marketplace isn't scratching at this yet) and get it working but some things just are not possible remotely from a plugin.... Im open to opinions?!

[ThorbjørnS]

Well. We have no big issue parting with $, we went with ondemand as we don't want to host JIRA ourselves. We have better things to do. And it would be awesome to use JIRA for our support purposes as well, not just internal tracking.

I don't understand why JIRA don't allow for external users to create tickets and get notifications. If they did, JIRA would be a fully fledged helpdesk system and beat a lot of the competition in that market as well.

[ipguy]

I guess I could just let jira setup the account but not send the auto account creation email

[Ivar]

So your challenge is not the number of license, more to avoid "spamming users"? From my point of view, giving them the possibility to access Jira and follow up on their own cases makes it much easier for you (Helpdesk) to do your job :)

[Ivar]

It is possible, but it's a bit tricky. The main challenge is that all issues registered will belong to 1 "helpdesk_client" user, so it is difficult to differentiate the different customers from each other. We managed to do this by picking the e-mail adr. from the incoming mail and copy this information to a custom field.

Workable, but I'm not sure if I'm that happy for the solution. Best way would definetly be to have 1 customer = 1 Jira user.

[Andy Brook [Plugin People]]

It depends how you see ongoing relations and interaction with the user. JIRA kind of expects users interacting with the system to be able to login, however, you can use JEMH to create users that do not take 'seats', are not able to login to JIRA but are able to be part of notifications, request/response. The issue with that is that without full range email template customization, all emails scream hyperlink to this issue, which they are not able to login and see.

JEMH also has features to copy non-jira user email address to custom fields, which can be used as part of an overall solution, that JEMH does not (yet!) encompass, https://studio.plugins.atlassian.com/browse/JEMH-524 duly raised!