nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How do I setup JIRA Service Desk? Want one centralised support portal, but multiple clients/projects?

Mark Haller

Hi all

I've just installed JIRA Service Desk. I'm a long-term JIRA user, running a web design/dev agency - we've got around 50 JIRA projects, split across around 30 clients.

We currently are using Zendesk and we want to get rid of it, and replace with JIRA Service Desk.

Currently our staff use Zendesk to get/see new issues coming in from ANY client ... and all our clients login to the one support portal at Zendesk, or email into it to raise requests.

So ... I need to be able to see the current status of all tickets across the company. I also need to see tickets for a particular client.

My question - do I create one project for JIRA Service Desk (so LogicSpot Support) and every client and user uses that? If so ... how do I then get the ticket across to the correct project later?

Or do we create one JIRA Service Desk per client into the existing projects? If so .... how do we see "all tickets" and get the benefit of the new SLA reporting, etc ... across my company and staff clearly? And then ... if it's one per client/project ... then can I create a template and copy that to all projects easily?

I'm really confused - any help appreciated.

Accepted answers

All comments

Judd

Hi Mark

I'd suggest creating a single Service Desk project. This will give your clients one location to raise tickets and your team one location to prioritise/process/report on those tickets.

If you need to create support queues by client, you could use the Component field or another custom field to record the client on each ticket and then build queues from there.

When you say 'get the ticket across to the correct project' do you need to move the actual support ticket or is this in relation to an associated development issue?

Assuming development issues live in the 50 JIRA projects you mentioned, one approach would be to link development tasks with support tickets via an issue link. When the development issue is complete the client can then be updated via the support ticket.

Another method for development teams that use a JIRA Agile rapid board is to pull support tickets into each teams rapid board based on team labels or an 'escalated to dev' type custom field. This allows each dev team to see tickets that they need to action while keeping all support items together in one project for SLAs and reporting.

Hope that helps a bit. Let me know if you've got more questions and I'll try to give you a hand.

Mark Haller

Hi Judd. You've actually made a great suggestion ... and got us talking about changing our whole approach to support. Right now our support is too close to the developers/second line resources .... so impacting their time often, and difficult to maintain so adding a service desk per project/client would've made sense initially but it's maybe time to change our operating model. I also assume Atlassian's approach is the one you're recommending and not throwing in scores of Service Desks in JIRA?

Can you tell me - right now we have some really great reporting against billable and non-billable tickets ... we've even written our own PHP wrapper and front-end that clients can see at any moment in Confluence where their monthly support hours are being spent per ticket, and backlog, etc, so they don't need to go into JIRA ..... so I want to make sure we keep all that. Can we connect or show the original issue from Service Desk any other way against a JIRA project other than linking? Just an idea.

We don't use JIRA Agile.

Another question - is having one Service Desk going to give us the flexibility that each client can login and see just their own tickets ... or their company's tickets (if they are at a senior level)? I'm worried about all tickets in one JIRA project and lots of client confidential data!

And my last question for now - will it be possible to map a client's name/email address across to a "Client" field with ease for any new ticket? I've not done this before.

Mark Haller

Hi Judd. You've actually made a great suggestion ... and got us talking about changing our whole approach to support. Right now it's too close to the developers/second line resources .... so adding a service desk per project/client would make sense .... but a nightmare to maintain ... and I guess not the route that Atlassian is taking with the recommended implementation architecture of the product.

We don't use JIRA Agile.

And my last question for now - will it be possible to map a client's name/email address across to a "Client" field with ease for any new ticket? I've not done this before.

Judd

Hi Mark,

No problem This is the approach we recommend - centralising support into one project rather than creating dozens of little service desks.

Connecting issues in JIRA is usually done via issue links. Depending on how your script works you could potentially:

Modify your script so it looks both at issues in the client project and issues in the Service Desk project labeled with the client in question
Copy completed tickets into their client project so your script can reference them
If you use the JQL Tricks plugin, you can find issues linked to a given client project in JQL using linkedIssuesInProject and then have your script reference the resulting list

There might be other approaches too depending on how your script works.

In terms of confidentiality, you could set the issue level security of a ticket to ensure only appropriate users can view it.

There are also two open feature requests on JAC that might apply to your situation - you're welcome to vote and/or comment on these:

You could potentially configure a client field in a few ways:

Create a custom field called 'Client' and make it visible on the Customer Portal (relabelled 'Organisation' or similar) that the client can directly fill in
Setup a workflow post-function to set the 'Client' field based on other field values like name and email (depending on how complex your rules are this might need a plugin like the JIRA Workflow Toolbox)
Have your support team set the 'Client' field when they first pick up the ticket

Judd

Hi Mark,

No problem This is the approach we recommend - centralising support into one project rather than creating dozens of little service desks.

Connecting issues in JIRA is usually done via issue links. Depending on how your script works you could potentially:

Modify your script so it looks both at issues in the client project and issues in the Service Desk project labeled with the client in question
Copy completed tickets into their client project so your script can reference them
If you use the JQL Tricks plugin, you can find issues linked to a given client project in JQL using linkedIssuesInProject and then have your script reference the resulting list

There might be other approaches too depending on how your script works.

In terms of confidentiality, you could set the issue level security of a ticket to ensure only appropriate users can view it.

There are also two open feature requests on JAC that might apply to your situation - you're welcome to vote and/or comment on these:

You could potentially configure a client field in a few ways:

Create a custom field called 'Client' and make it visible on the Customer Portal (relabelled 'Organisation' or similar) that the client can directly fill in
Setup a workflow post-function to set the 'Client' field based on other field values like name and email (depending on how complex your rules are this might need a plugin like the JIRA Workflow Toolbox)
Have your support team set the 'Client' field when they first pick up the ticket

Mark Haller

Hi Judd

This is all good stuff and taking me forward - some big questions still to resolve, but getting closer.

I'm going to look into the JIRA connection using Issue Links. I think myself, like many other organisations, might get to a state of working out at what point a service desk ticket becomes the initial REQUEST and the REAL BILLABLE WORK takes over - and whether that is all in SD, in SD linked to billable tickets in other (client-specific) projects, or something else. We're documenting our approach currently and it's getting clearer :-)

The setting the field thing is a bit poor from my perspective using JIRA. I kind of expect this built either into the core JIRA product, or included (as a pretty high priority requirement) in the core Service Desk product - having to spend yet more money, buying Service Desk, a LOAD of extra users (cos the current payment model just doesn't suit), etc, .... I'm now looking at many THOUSANDS as all products in my Atlassian setup need upgrading at the same time - so I need about another 15 users, but my upgrade will be from 50 to 100 .... buying yet another product that just allows me to set the ticket requestor's COMPANY is pretty poor :-)

I've tried JIRA Plugin Pack but that wasn't updated in around 3 years - tried it and it's not playing and the documentation is non-existtent.

I've tried JJupin on trial, but so far I can't get it working - I added a field, and linked with SIL script on the creation of the ticket in the Helpdesk ... but that fails with a cryptically simple error message -and trying to delete the custom field and start again gives me a big Java error.

Others are just cost-prohibitive I think.

Thiago

Hi Judd,

Can I just please add another question in here in order to get more details on the confidentiality aspect?

Firstly a very brief background, I have been using JIRA On Demand with Agile boards for a couple of years now, and am now in the process of stablishing our support process using the Service Desk Customer Portal.

I understand that, in order to protect clients from viewing each other's tickets, you would need to setup the appropriate security level of a ticket, as you said.

My question is:

Would you be able to automate the setting of the issue security level to the appropriate 'client', possibly though a custom field, using On Demand Service Desk, when clients raise their tickets via the customer portal?

Or would it be a manual task for a support team to take as they pick up a new ticket, and change the issue security level at the point?

Thanks

Judd

All good. Often throwing solutions at things helps clarify the need

I understand that plugins can be tricky. This is good feedback, thanks.

In your situation is the goal to enable every user from a given 'client' to see all requests for that 'client'? There is an open feature request for this specific use case: JSD-270. I'd encourage you to vote and/or comment on this if that is your use case.

If your customers only need to see the requests they individually raise, but you need to track/report on issues across all users from a given 'client', you could potentially:

Use the Portal-only permission (JSD-62) which has been implemented for Service Desk 1.2
Place each user in a group based on which 'client' they belong to
- Locate issues from a specific 'client' using JQL: reporter in membersOf("client-group-name")

Mark Haller

Hi Judd

My needs are a little simpler - I want to set a client organisation field on the ticket when the ticket is raised.

We actually don't let clients use JIRA itself as the interface is just too complex/complicated for them - instead we took the JIRA Macro that's for Confluence and rewrote it for our needs using PHP/REST. We actually have pages in Confluence for each client, whereby any member of their client team can go in, see their current tickets, backlog, that month's support/dev we're doing, etc - it works beautifully!

So what I need is to set the ORGANISATION when a JSD ticket is raised ... then I'll just tweak my JQL queries a little on each client's Confluence pages - that gives us two things -

the ability for each requestor in JSD to see their own tickets and process them using JSD/workflows/SLA/etc;
the ability for any user at a client organisation to see all tickets and their status, as well as all other non-JSD raised tickets and dev work in Confluence

To me the request seems SO simple - add a custom field to the user for organisation, and we add that each time we add a new person to JIRA. Pull in that custom field onto a ticket when a ticket is created. Not rocket science hey? :-)

unknown

We have a very similar requirement - lots of different clients accessing the same service desk, and I would love a simple way of enabling different users from the same client to see each other's issues.

We currently have a custom "client" field that we have to set manually (rather than expose this on the service desk form). I would love this to be be able to be defaulted depending on which user group the user is in, but this doesn't seem possible. I've even tried using Bob Swifts Conditioned Workflows add-ons to do this, but even this can't handle IF user_id in memberof(ClientA) then Client = ClientA.

We've set up issue level security, so that external clients can only see issues that they're assigned to, or that they reported, but this is quite limiting.

We've also considered, and rejected, having one service desk per client, although we do have (at least) one development project per client. Once issues move through the service desk (and triage), if they can't be resolved we "Move" them to the development team (rather than linking as it's less error prone). For client reporting we then have a JQL query that joins service desk issues for that client, with issues from the dev project

unknown

WARNING - there is a major bug with the way Service Desk works (or doesn't) with Issue Level security at the moment (https://jira.atlassian.com/browse/JSD-367)

As such Judd's advice won't currently work. We're totally stuck with this - and really disappointed by yet another problem with makign service desk work for our organisation.

Mark.

ernests lipko

Hello Mark!

Seems you were facing the same problems I am facing now . It was a good read.

Have you achieved any progress with this challange?

Mark Haller

Hi there

Yes I have - insofar as we've had to find an alternate solution until JIRA Service Desk is aimed squarely at our needs. I know they had to choose a particular target customer for first release, and I think it's still focused the same place as I'm writing this. When the cost model and security model and various other things shift, I'll look again - but for now we are sticking with Zendesk, with a view to move to Freshdesk in the near future.

I see maybe JIRA Service Desk a better long-term punt for us .... as we're using JIRA, Confluence and other Atlassian products heavily all day.