Hi all, I’m looking for some guidance on a challenge with JSM and Confluence as KB. We have a standardised JSM project used by most of our customers. One large customer was previously on a separate, customised support setup, and we’re now migrating them into the general service desk. They have product specific documentation that shouldn’t be visible to our other customers. Sensitive and irrelevant, potentially confusing to other customers. Atlassian has documentation suggesting to invite customers as Atlassian accounts to allow assigning them to groups and restricting content that way. However, when testing this, we found that any user with an Atlassian account, even with just the customer role and no confluence license, can navigate directly to our confluence and view KB articles of any service project, even the ones they do not have access to ad a customer. This would potentially expose internal teams KB’s such as ICT, legal, HR, … which is obviously not acceptable. Am I missing another way we can achieve this? How do you handle customer specific documentation without exposing other Confluence spaces? My personal gut-feeling keeps telling me they need a dedicated JSM project for this, but management has made the customer promises and has been working on this for months before it reached my desk and dont seem to want to backtrack now. Any insights or experiences with this subject would be greatly appreciated! Cheers, Thijs

Hey everyone 👋 I’m setting up a Jira Service Management project to handle all internal Atlassian requests: incidents, access, changes, new projects, and general questions. For basically all Atlassian products. While Atlassian provides starter templates for different teams, there’s no clear blueprint for an admin team’s own service desk, the place where users go to: - raise issues or improvement ideas for Jira, Confluence, Statuspage, Loom, Opsgenie, Marketplace apps, … - request access, new projects, or configuration changes, - and find internal documentation or governance info. I’m building this right now and would really value your short-term advice and general pointers: - What request types and fields are worth starting with? - Which workflows and automations keep things lean but effective? - Would it make sense to track any of this in Assets? - And how do you approach reporting, showing demand, workload, and the value of a dedicated Atlassian admin team? Longer term, I think this could be a great community guide or mini-course — a practical “Atlassian Control Hub” blueprint that any admin team can adapt. Something simple, scalable, and built by the best of the best admins for other admins. How are you handling your own Atlassian admin intake and reporting today? Thijs