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; } } }

Customer portal self sign-up and private/protected knowledge base

Thomas81

I've reviewed https://confluence.atlassian.com/display/SERVICEDESK/Providing+self-help+resources+for+your+customers+with+a+knowledge+base and found that our desired scenario seems not supported at the moment. Maybe somebody can proof me wrong.

We would like to create multiple service desks (with each connected to a different space in Confluence).

The users for each service desk are different and generally would belong to a certain domain so we could identify them using their email address. The customers options right now are 'invite customers' or 'everyone can access' and both are not ideal.

Since JIRA and Confluence have to have the some users in order to allow the users to search the knowledge base space in the Customer Portal we would need to create a Confluence instance for each Service Desk (Customer Portal) using the JIRA as external user directory for Confluence.

Can we achieve a Customer Portal with self sign-up and private/protected knowledge base? Or am I simply describing what Zendesk would offer already?

Any comments are appreciated.

Accepted answers

All comments

Charles Wells

Thomas, I may be missing something and if so, I do apologize. However, it sounds to me the only issue is getting the customer accounts into proper groups for requisite Confluence space access.
I say that because:

having multiple service desks each connected to a different space in Confluence = yes, as you've read
Customer Portal with self sign-up = yes, Customer sign-up
restricting Confluence space access = yes, by Space Permissions
The users for each service desk are different = so that means you'll be providing each group of customers a unique service desk portal URL only for issues / knowledge base with which they will interact

As you're using JIRA to manage users, it seems to me the accounts will be created in Confluence and again, the only missing step is placing them into groups assigned for Space Permissions. You could do that manually, or probably automate with some scripting leveraging the email domain.

I'd enjoy being able to assuage your concerns, so please clarify where I may be misunderstanding and I can loop in colleagues as well. From what I gather, JIRA Service Desk can do what you need it to do.

Thomas81

Charles, thanks for your answer. The problem I see is that I can have unlimited customers in JIRA Service Desk but need to have them licensed in Confluence so they can view content (we don't want them to create/modify). The licensing change for Service Desk 2.0 was a big step in the right direction. But it seems to be not consequent enough, because being able to provide self-help resources and searching Confluence pages is a big value in the customer portal.

Licensing issues aside, we are actually utilising CROWD for our internal users in JIRA and Confluence, so we would need to change or can we simply connect another user directory in Confluence?

Charles Wells

Thomas, I've also come across this add-on for Confluence which restricts content visibility based on several parameters. https://marketplace.atlassian.com/plugins/net.customware.confluence.plugin.visibility

Charles Wells

I'm not aware of any reason why you'd need to change from CROWD, but I'm following up with colleagues to ensure completeness around the user management piece.

Charles Wells

Thomas, since you are using CROWD, please review this recent article for any appropriate steps. https://confluence.atlassian.com/pages/viewpage.action?pageId=677085280

Charles Wells

Thomas, additional info from my colleagues Chris Pepe and Lindsay Barton: Custom development is probably the way to go for exactly what you've described for the space access. A new user directory wouldn't be necessary, but the new users will have to either be named Confluence users (and count toward the license) OR the Confluence documentation needs to be accessible to anonymous users. If you're behind a firewall or if the KB articles aren't sensitive that would work without affecting user licenses.

Charles Wells

Thomas, there is the option to turn on anonymous access at the instance or space level. Please review this article to see if it would alleviate any of your concerns.

https://confluence.atlassian.com/display/DOC/Setting+Up+Public+Access

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira-service-desk