How to set up hierarchy

[Marcin Krasicki]

Hi all !

I'm wondering is it possible in Jira Service Managmet to set up this:

We have partners who have they own clients, we want partners to be a first line of support for they customers.

Customers must be assigned to a partner .

Partner only see ticket of his own customers.

Partners cannot have admin privilages in Jira.

All partners must be able to assign ticket to lv 3.

LV 3 is us. We need to be able to see every ticket there is. Even if it didnt come to us yet.

Customers only see they own ticket and ticket rise by anyone in customer organisation.

Customers cannot see other organisation or partners.

Both customers and partners should have access to customer portal.

Customers should be limited to access issues from customer portal.

Partners can use Jira Service Managment if it can be configuerd the way so they will not be able to change anything important.

Both should be able to browse knowlage base that is connected to confluence.

Would be great if this was possible using one project only.

Can anyone share a bit of wisdome on this please? :)

A quick guide would be appriciated if possible.

Thanks in advance!

[Brant Schroeder · Accepted solution]

@Marcin Krasicki Welcome to the Atlassian community

There are two ways I see this working in Jira service management.  One, you set up a service desk for each partner.  They would then use this with their specific customer and escalate issues to your team via a workflow.   This would be the easiest way to accomplish this.

Two you could have a single service desk but use issue security so that your partners only see the issues associated with them.  This is more tricky as you would need something on ticket submission that applies the proper security.  It could be a selection field, request type, etc.   If the issue security failed to apply because it did not meet the criteria then all partners would see the issue or it could be assigned the wrong issue security making it go to the wrong partner.  The other problem with using issue security is partners could technically see other partners if they tried to add watchers or make assignments.  

[Marcin Krasicki]

Hi @Brant Schroeder .

Thanks for your take on this.

Setting up a different JSM for each partnet isn't an option.

I forgot to mention in my OP that it will be registration only thing.

So only reigstered customers can access JSM. 

I was thinking something like that:

1. For each partner create different organisation, and set a partner as an agent.

2. Add this partner clients to this organisation (ideally if partner could to this by him self without access to all admin rights)

3. Use automation rules to assign issue to partner if anyone from his group create one.

4. Use workflow like you suggested for partner to be able to send this to us if he cannot solve this on his own.

5. Upgrade to standard edition to be able to use issue security scheme like your suggested and setup this so issues will be only visible to reporter, or anyone from his organisation and in group lv3 that would create for us. But from what I see, I cannot create scheme with organisation selection, only group and/or  role

I'm kinda new to JSM and that's what I figred out after a day of playing with it, and reading about this.

What I do not know, will this be enough to meet all the criteria mention above, or do I need to do something more. If every partner would be an agent they propably will be able to see ticket from other customers that are not in his group.? 

I wish to limit this to single JSM instance and one project for my pice of mind later when number of partners will grow.

[Brant Schroeder]

@Marcin Krasicki 

If you add someone to an Org they will be able to see all the issues associated with the organization in the portal.  In the agent view, agents will see all issues available to them.  Issue security is set up by groups so you would add the agents/partners supporting an organization to a specific group.  Then when individuals from these groups submit a request you would use automation to set the issue security.   If someone was not in an organization you would have to assign it to a security group that only L3 would see and you would have to update and assign it to the proper partner.

[Marcin Krasicki]

@Brant Schroeder 

ok so to meet those criteria, i would need to create a new group for each partner,

create organisation for each client, put partner to each new organisation with his clients,

then create issue security to issues be visible for reporter and ppl from his org and L3,

then each new group add to automation to assign issue to partner, as there is

no simple filter in automation that does > if reporter is from group assign to agent in this group .. ;/ 

all i can do is if reporter is in group a assign to group a ..

did I get it right?

will this set up limit agent access to ticket only from his groups? imho no... can this be achived somehow?

that's damn tedious....

[Brant Schroeder]

@Marcin Krasicki 

You are almost there.  

1. Add customers to the orgnaization (Create org if it does not exist)
2. Add partner to partner group (Create a partner group if it does not exist)
3. Create security groups and add partner groups to the security groups
4. When an issue is created use automation to identify the organization and assign proper issue security to the issue.  This will make it so that only the partner in the security group can see the issue.

You are correct.  A lot of steps which is why having multiple service desks is easier.  It would also make it easier for individual reporting to see how each partner is doing.  

[Marcin Krasicki]

@Brant Schroeder thanks for all your imput, the issue with multiple project is that L3 would need to jump thru different projects, but I found an app that integrates different project in one queue, so after all I think we would go this way.

Once again, thanks.

[Brant Schroeder]

@Marcin Krasicki you can also use dashboards for your L3 team members so you don't have to pay for a third party app.  Just wanted to point out that option.