Best practice for setting up an 'customer issues' project within an existing Jira installation that is configured around tracking 'internal' issues

[Maarten Metz]

We are currently running a Jira instance that contains of a number of projects in which we track internally raised product issues i.e. QA finds issue, documents it, Dev fixes it etc. etc.'. A very basic, out of the box, work flow to which we have made a very small set of customizations.

We now enter a new phase where we want to track customer generated issues as well, and give anonymous users read-only' access to the project(s) against which they have reported issues.

I am leaning towards creating separate Jira projects to track these customer issues, as the workflow will be different from the workflow associated to the 'internal' projects. Customers will be able to indirectly create issue by making email requests.

I am a nembie when it comes to configuring Jira. I have been reading up on the existing documentation, but before I start making any changes and potentially cause some damage or develop an environment that will eventaully be hard to maintain, I would like to know what is the best practise around implementing this scenario. I assume that I will be best off creating my own sets of 'Issue Type Scheme', 'Workflow', 'Screens' and 'Permissions' schemes based of the default schemes?

Any help/pointers will be much appreciated.

Thank you very much,

Maarten

[Radu Dumitriu · Accepted solution]

If there is no sensitive information in the project (i.e. you have not much to hide from the customer), I recommend you to use a single project approach (i.e. customer creates issues in your project, issues that are further classified)

For permissions, please see this:

See this https://answers.atlassian.com/questions/8665/how-can-we-implement-the-concept-of-a-customer-entity-in-jira

[francis]

You can use the create and link new issue to split off a development task from a customer issue, and automate the interaction between the two using some groovy scripts (check the script runner plugin), in such way that if the development issue reaches a completion state, the customer issue is automatically progressed to resolved.

We described this approach on our website
http://www.idalko.com/display/WIC/Separation+of+specifications+and+tasks

It has some nice benefit, in case you have multiple customer issues which can be resolved with one development task, or when you have a customer issue which needs multiple tasks to be completed before you can consider it as done.

It's not a plugin for the moment, because with every new implementation, we do see some permutation in the approach.

Francis.

[Amedee Van Gasse]

Hi Francis, your link asks for a login+password.

[francis]

The page moved to another location in the mean time ... thanks for mentioning it. http://www.idalko.com/display/IW/Separation+of+specifications+and+tasks

[Heather D]

Hello! We actually have a very similar problem and would love to find a good solution. Background: Our sales team initially began using JIRA to track customer issues. It was very basic and was a huge improvement over tracking everything in email. JIRA was a huge hit and our tech team started to use it to track their issues as well. The sales team enters their requests in one project, and the tech team uses another project.

This is becoming problematic, however - when a salesperson enters a request, we need to clone the ticket from the sales silo to the tech silo. This creates a lot of extra work and duplicates the # of tickets. Additionally, when a developer begins working on their issue, the salesperson's issue is not updated and shown as being "in progress", so we have to manually go back into the sales team issue and update the tickets. It is becoming VERY CONFUSING.

Is there a recommended workflow for this type of situation? We want the sales team to have a very basic interface for creating issues, we want the opportunity to review the issues before passing along to the tech team, and we want a more detailed interface for the tech team to enter data and track the request. The sales team wants to see the client information (client name, user name, etc), but the tech team wants to see other technical information (version, networking info).

Can each team have different views of the same tickets? Can we filter out the "technical" noise from what the sales team sees and vice versa? Can we have a stage where the product development team reviews the project before passing along to technology? PLEASE HELP! thanks

[Radu Dumitriu]

There are many workflow customizations available. I would generally avoid cloning issues, just for the reasons you lay above.

In general, you should design a workflow that will cover both sales and tech processes (it's the same issue, different views). For that, there are a number of plugins that may be of help, search plugins.atlassian.com after scripting plugins.