Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Best Practices - Setting up JSD to support many external companies

Jack Brickey Community Leader 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.


  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.


  • 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.


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.




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.


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.



Log in or Sign up to comment