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!


In Jira Service Management, can I control what articles the public sees?

We use Jira Service Management to collect issue reports on our products from employees, beta testers, and VIP/partners. It is also a great way for these parties to find documentation since not all of them are great at using confluence.

Each product's service portal is linked to that product's confluence space, so employees (who do have access to that space) can see all the documentation pertinent to their questions because the space is set to private in the knowledge base permissions:

2021-10-20 08_50_03-StagesBike - Knowledge base - Service project - JIRA.png

The problem I am trying to solve is we have some documents (Repair SOP, Troubleshooting guides, Release notes, etc.) that I would like those beta testers and VIP/partner groups to be able to see from that space, but I do not want them to see all of our other documentation.

Is there a way to select which articles an "organization" in Jira service management can see, and limit them only to those articles, without having to create a separate space for those particular articles?

2 answers

1 accepted

Suggest an answer

Log in or Sign up to answer
2 votes
Answer accepted
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Oct 20, 2021

Create 2 permission groups for this space, naming them whatever makes sense for your use case "restricted-readers", "content-contributors", etc...

"restricted-readers" will need read access to the space, while "content-contributors" will need at least the ability to read/add and delete if that is required.

Any content you don't want VIP/partners to access should have permission restrictions applied and allow only "content-creators" to have access, removing "restricted-readers".

The space would require to have good content organization so you are not applying custom permission restrictions to hundreds of pages.

@Matt i agree, this would work for sure. Similar to @Elliot Reiter's suggestion above this is a good solution however I am doubtful our organization can achieve this effectively. Im hoping for an admin based solution so I dont have to train the organization on restrictions. I really appreciate these suggestions but I am sure you've found that getting users to do something like this can be difficult and ideally I would manage it with an admin structure. 

Like Gazaliy Alade likes this
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Oct 20, 2021

Hmm... I don't believe there's much available within the Admin portal for this use case. The only way I could see doing this would be via permissions/restrictions. But if you're comfortable with development against the API you might be able to conjure up something.

With the API method, if your org is comfortable with tags/labels, you could label each page in the space with an appropriate tag and then use the permissions/restrictions API to grant/restrict access based off of the label. Not an easy task but should be possible and your users wouldn't have to get their hands dirty (besides adding a label, but that could also be scripted)

That is a pretty good solution! I wish I were more comfortable with that kind of work, because I think thats a good way to go. 

Ill keep watching this ticket to see if anyone else has some ideas here, but maybe I can take some time to learn more about this suggestion. 

In the meantime what I will probably do is create a different confluence space for externally approved documentation of these types and use the "Restricted" permission setting in the knowledge base for each portal.

@Jim Stemper I still don't think it's necessary to have separate Confluence spaces, when it would work in one space.  As an example, have two top level pages with a child page structure as follows:

1. External Facing pages (set a page restriction for view-only for your external users here.  The child pages will inherit the view-only restrictions)

       KB Topic 1 (you can set page restrictions here for any specific external group you create)

       KB Topic 2 (you can have different page restrictions here)


 2. Internal Facing pages (the page restrictions should exclude your external users here.  All child pages will inherit that restriction).

Hope this helps.

Like # people like this

That can work! Thanks for this suggestion. We will go with this!

@Jim Stemper ,


You can try to use the Page Restrictions functionality in Confluence.

I would had given the same advice, even if not sure if they apply to Confluence only or to Jira SM portal and KB as well. But it would worth a try.

Yes, definitely worth a try.  Once someone clicks a link to a confluence page, Confluence security and permissions take hold.  I recommend putting the beta testers and VIP/partners in a group and set page restrictions to allow the group to view that page and any child pages.  Then this group can be set to have no permission to all other parent pages.  It's important to organize the page structure in the space well.

Like # people like this

@Elliot Reiter That would work for sure, however, that would require our entire organization to learn about restrictions for all of our documentation, and I have found that the less extra things I require of our users the better (im sure you understand this). I appreciate the suggestion but im hoping for something that can be done on the admin side instead of something i need our users to learn and implement.

@Jim Stemper It seems to me it will only be on the admin side.   The designated administrator of the space or the overall Confluence Administrator are really the only ones that can set Page Restrictions anyway, not everyone in the organization, so it most likely means just a handful of people.   Space admins and Confluence Admins should already know how to set Page Restrictions.

@Elliot Reiter agreed. That is a good point. Can you set a rule that every new page that gets created has a restriction applied?

@Jim Stemper I believe automation in Confluence is only available on a Premium support plan.  My company is on the standard support plan, so automation is not available for me to give you a reliable answer.

The only rule I'm aware of is If you add a child page under a parent page that already has restrictions, the new page will automatically inherit the parent's restrictions.

Like Jim Stemper likes this
AUG Leaders

Atlassian Community Events