Best Practices - Setting up JSD to support many external companies

Jack Brickey Community Champion Apr 12, 2017

We have been using JSD for internal support (IT, Facilities, Staffing, Purchase Requests, etc.). We are now assessing for use as a support portal for external customers. I'm looking for input from the community on best practices and things to avoid.

Requirements:

  1. Inter-Company Access - Customers from one company MUST NOT be able to access tickets from another company. 
  2. Intra-Company Access - Customers from within a given company SHOULD be able to access issues created by others in their company. However, we also MUST be able to control this at the user level, i.e. some companies may wish to control who can view all other company created issues.
  3. We MUST maintain independent portal view/access for our internal and external customers. We don't want external organizations seeing internal portal content.
  4. Automatic Company Identification in Issues at Creation - The 'Company/Customer' field MUST be properly filled in based upon the customer/user.
  5. The ability to have unique SLAs per company is a MUST.
  6. Knowledgebase - The solution SHOULD allow for common shared documents as well as company specific articles, i.e. Company A & B can access 1, 2, 3, 5, 6 but only company B can access article #4.

To get things started I am initially thinking of the following model:

  • A single Help Center portal for all external customers
  • Setup Queues based upon Request Types (Tech Support, Billing Inquiry, General, etc) to align agents appropriately.
  • Use the Organization feature to group users by Company to satisfy #1 & #2, or even Organizations w/in a given company if we need to control the intra-company access as mentioned in #2 requirement.

Questions:

  • Can/should we set this up using our current JSD cloud instance which runs as a application on our current JSW cloud instance? That is could/should I create a 'Customer Support' project w/in my current JSD and meet all my requirements. Particularly important is to separate out what my internal and external customers can see and access if I'm using a single portal.
  • Can I achieve all of my MUST requirements?
  • What things should we avoid doing when setting this up?

I apprecaite any thoughts from those using JSD in such a manner.

2 comments

Susan Hauth Community Champion Apr 18, 2017

Hi Jack,

We are presently setting up to roll out JSD for our external customers.  We have requirement #1, customers can only see within their company. So we use Organizations and the Customer Permission "other Customers in their organization". 

I"m not really sure how to handle #2 with dis-allowing users to not share other issues within their organization.  I haven't seen anyway to do that yet. 

For #3, that should be straight forward if you keep external customes in one service desk project and internal ones in a different one.  At least that's how I'm planning on doing it.

For #4 we have the same requirement.  We tediously maintain for each external user in their properties their Customer Name and their tempo account.  A post-function on the workflow on create then takes the reporter's properties and places them into custom field "Client".  If there is another way, all ears.

#5 - That should be easy as you can write any jql for the SLAs.  So user is memberof{"group for that client") gets their own SLA, calendar etc.  We will be doing that for a set of our clients who are Global clients so get 24/5 support versus just office hour support.

#6 - No idea how to manage that.

Just a hint, we are using Intenso JSD Extension.  Very useful for segregating our groups by request types. 

Keep me posted on how you get along.

Susan

 

 

Item 6, shared and organization specific knowledge base articles is also something I am after. Would really like to know if this is somehow possible.

Without this we would need a JSD project per organization which I suspect may complicate things.

S.

Susan Hauth Community Champion May 26, 2017

Hi Scott,

Yes that complicates things.  You could probably get fancy and put restrictions on the KB by the group that your users belong to.  As there is no concept yet in Confluence of Organizations that would mean maintaining those users into a group as well as an Organization.   

You can restrict by label to request forms, but then you would need to restrict request forms by orgs.  Still would need groups and the Extensions for JSD plugin.

Keep me posted on which way you're leaning.

 

Comment

Log in or Join to comment
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

3,196 views 13 19
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot