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.
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:
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.
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
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.
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.
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?
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
...+ reading Fantasy). The same is true for him at the bank he works for: Efficiency is key when time literally equals money. Read on to learn how Sergey makes most of the time he has by...
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!
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