Automatically assign issues to a user based on DB extract.

[Sébastien Pepinster]

Hello everyone !

First of all, let me warn you : There might be plenty of rookie errors and misconceptions in my post. This is due to me not having an IT tech background and being a Senior Business Analyst with CRM specialization. Please forgive me if some of the things I say seem stupid, it's the exact reason I'm here : learn from your experience to improve my communication towards JIRA specialists. :)

So here's the situation I want your insights about :

I'm working on the implementation of JIRA as a task management tool for multiple production teams.

The idea is to integrate a mailbox for each project (1 team/project) and have the requestors send the issues via mail.
We've already configured JIRA to detect some keywords in the subject of the email and, in each queue, associate a "type" (e.g. "new business", "renewal", "cancellation"...) to said issue.

However, my business case is a little bit more complex :

Each issue entering the queues is about one single customer. And each customer is assigned to a specific portfolio manager.
Right now, the requests enter in the team queue and have a type attached by JIRA, which is good. However they're not assigned to the correct portfolio manager and assigning them manually is a pain in the a**. :)

Therefore, I'm investigating the following solution : 

1. Integrate a database extract in JIRA. This DB would contain three columns -Client number, Client Name, Name of the portfolio manager-
2. Upon sending an issue to the JIRA integrated mailbox, the requestor would write the client number in the e-mail subject.
3. Have JIRA detect said client number.
4. Have JIRA query the integrated DB extract and match the client number in column A to the Portfolio Manager Name in Column C.
5. Assign the issue to the relevant portfolio manager.
   
   Or
   
   Display the value of column C in a column on the "unassigned issues" list page, making the manual assignation process easier.

 

So what do you guys think ?

a) Can JIRA do such thing ?

b) If so what is the best approach to make it do this ? Custom script ? Plug-in (nFeed ? Database Custom Field ? Other ?)

c) Has anyone of you already faced that kind of business case and did solve it in another way ? How ?

d) Is Santa Claus real ?


Sorry for the long post, thanks for your knowledge and looking forward to reading from you.

Cheers from Belgium,

SebPep.

[Mirek]

First of all it is better to not ask customer to put anything to email. They will not do it and your process do not work. You need to think about a solution that would included information that you know. For example an email is already something that clearly define your customer. So you need to read email address and based on this build your custom feature...

Everything else depends how many clients you would have. This define better approach since you can use simple script in post function (with if .. else) or more complex solution like reading from a external database or file.

If using second solution there are many ways of doing that but mostly you need to use plugins like nFeed. This should be easily possible since you can connect to a database or file on the server containing key-value data and use this to fill other fields. Logic could be also included in post function (for example when transitioning from first status in a workflow) or automatically when ticket would be created.

You can also have a completely external script that using REST would explore your JIRA projects and make changes to it based on field values (logic then is outside JIRA). It could also connect to database or file if needed. That is more like a free solution. Simple development. I hope that it is clear what I mean :)

[Sébastien Pepinster]

Hi Mirek !

Thanks for your answer.

It seems that there was something unclear in my description above : This is an internal process only, meaning that it isn't customers who send the issues via e-mail but internal colleagues from another part of the organisation.

1st line people type the issue, send it to the correct second line mailbox and within each 2nd line queue, a portfolio mgr handles only the issues related to the customers he's in charge with.

Those 1st line colleagues would be trained about the correct process (mention client number in the email subject) and would accept the risk of having a slower SLA on issues in which they forgot the client number.

Of course this would never 100% be fool-proof but it's an imperfection we're ready to live with.

Unfortunately, then, detecting the requestor's email isn't a valid solution since they can be any 1st line agent (about 100 people) and could potentially escalate a request about any customers (about 10.000).

So I'm happy to know that I wasn't mistaken about the possible script/nfeed plugin solution for the DB linkage, however, this doesn't solve the problem of mapping the portfolio manager based on client information part.

Hope my question is clearer now. If not, please, don't hesitate to tell me where I can improve my explanation. :)

Thank you again,

SebPep.

[Mirek]

@Sébastien PepinsterI think it is clear but in that design I just to not understand why you need additional logic to this. If you have 1 line of support that would fill all the details why they cannot simply type portfolio manager name (instead of client number/name) . Even more why you even need to send an email that would create a ticket instead creating the ticket already in the system.

When working in JIRA directly you can design a logic that when typing customer name/code in the form it could connect to external database and fill other fields values (like for example customer name and manager.. )

Similar design is when you contact Atlassiaan Support. You type SEN number and after creating the ticket support have all the details about the customer including other issues created etc.

So in other words email is the problem here. Simply put entire process in JIRA and your issues would be gone :) It is all about the workflow. You can design it in that way so that 1 and 2 line of support could use same information and also portfolio manager could be aware of tickets that he need to do. Overall when all customer details would be there manager could make a JIRA search using JQL and find all tickets from specific customers (or those tickets could show automatically on his dashboard when he log in to the system) . Tickets does not need to be physically assigned to him.

[Sébastien Pepinster]

I think it is clear but in that design I just to not understand why you need additional logic to this. If you have 1 line of support that would fill all the details why they cannot simply type portfolio manager name (instead of client number/name) . Even more why you even need to send an email that would create a ticket instead creating the ticket already in the system.

Oh Mirek Mirek Mirek, you're hurting me so bad !

This is EXACTLY the point I made to my Manager's Manager two months ago before I started analyzing this whole situation and I totally agree with you. :D

HOWEVER on an organizational level, the 1st line being a "profit center" and the 2nd line being a "cost center", it has been decided that the JIRA solution should be 100% transparent for them even if it puts more pressure on the development and maintenance of the tool, or makes the life of 2nd line more difficult.

Of course, being specialized in CRM, my first answer to the management was "Well, easy : we make a new issue page, the requestor logs to JIRA, creates an issue in JIRA, filling in all the fields, and there we go, no issue, routing is done automatically and every information is structured and beautiful."

Alas, the answer from 1st line management was "No way we log to yet another system to do what we already do (-even thought it's process bypass today to send issues by email-) : if we can't go on sending requests by e-mail it's no solution for us. Also, we don't want to lose time to find the portfolio manager's name in the backend system. Giving you the customer number should be enough".

And there we are, trying to find a twisted logic to implement into a tool, in order to fill-in for the laziness of a whole organization. :'(

[Mirek]

I really do not see any difference in time or complexity between filling a email window (where you need to put content/description) and for example Service Desk form (and Description fields). Overall I still do not understand why people like email so much. This is not quite safe and problematic layer of communication.

1 level of support could have only two fields - customer number and description and rest of the magic could be done after creating the ticket. Why a professional support include email in this and add additional layer that increase the risk of communication failure (if email would stuck somewhere or server would be down)

I suggest to develop two solutions as a pilot and give that to managers for testing/review. Maybe then everyone would see that email is not needed here :)

Overall if you still need to use email it should be possible. You just need to read email parameters (there are plugins for that also) and later define a workflow post function that after creation or moving through the workflow would execute logic that would assign ticket (add as a watcher or else) portfolio manager. You just need to choose tools (addons) based on your budget. Try with nFeed first (https://blog.valiantys.com/en/add-ons-en/external-database-jira-nfeed) .. You can also explore Power Scripts and Script Runner (maybe have some features that would help) .. or develop your own addon (or Post Function) :)

[Sébastien Pepinster]

From our discussion above, you know I agree with you about that "web-based interface solution", right ?

The reason I won't even bother doing a POC for this is that we ALREADY have our own "web-based" solution, built in house 5 years ago and that nobody is using. Their explanation for this ? Logging in a tool to fill in a structured issue takes too much time. Instead, they just forward the client's email they receive to a general mailbox and that's it. Amount of work done : 2 secondes. Efficiency of the work done : 1/10 but it's good enough for them.

The goal of the JIRA implementation is to allow those guys in the 1st line to bypass the web-based interface while allowing the second line to work on said web-based interface for obvious efficiency reasons.

And therefore my issue. :(

Anyway, my main issue won't be about budget but about compliance : not sure whether external modules will pass the JIRA risk assessment.

[Mirek]

Instead, they just forward the client's email they receive to a general mailbox and that's it. Amount of work done : 2 secondes. Efficiency of the work done : 1/10 but it's good enough for them.

For me this 1 line of support (if they do only this) is completely useless . Customers can directly send emails and those email could be parsed by the system and processed. No need have a middle layer that would only forward those emails.

But I understand. Some things (and people) cannot simply change. They are just one solution for years and that is the best for everyone.

Anyway I hope I was able to answer couple of your questions that you had. I am not a nFeed or other plugin vendor expert to give you exact solution but I think you are on a good way to develop your own.

However... I notice also now a pretty promising plugin that might be for you - SmartHandler - Email logic for Jira (https://marketplace.atlassian.com/apps/1217871/smarthandler-email-logic-for-jira?hosting=server&tab=overview)

Description says:

• THE PROBLEM? Organizations spend too much time and resource manually creating and managing multiple issues/tickets from information contained in inbound email or forms.
• THE SOLUTION: Automated issue/ticket creation & updates based on email content – SmartHandler for Mail from Forty8Fifty Labs.
• Automatically Monitor, Analyze and Act - SmartHandler for Mail allows Jira and Jira Service Desk users to automatically monitor, analyze and act on email or form content.
• One Email, Multiple Tickets - SmartHandler for Mail supports advanced, complex issue/ticket creation and update scenarios.  A single email can trigger multiple actions across multiple projects.
• SmartHandler for Mail - The most flexible, powerful way to make email actionable inside Jira and Jira Service Desk.

So something definitely to check out :) Maybe it could also replace 1 line of support if you set up this "email scoring thing" :)

[Sébastien Pepinster]

For me this 1 line of support (if they do only this) is completely useless . Customers can directly send emails and those email could be parsed by the system and processed. No need have a middle layer that would only forward those emails.

From the partial description I gave to you, I understand that you think that. The business is way more complex than my explanation, though, so we're gonna have to stick with this organization.

HOWEVER... That last plugin... man... If what they promise is real, this is EXACTLY what I need.

I'm gonna investigate further and see if I can build a POC in a shorter time than the free trial period. Hopefully this will help me to support a further business case. If not, back to the drawing board.

Thanks again for your time and answers, man. You've been a great help.