We synchronize all our employees from Azure Active Directory into Jira with Atlassian Access. Most employees do not get any Jira licenses, so they are just customers in our JSM projects.
We synchronize the Department and Company fields from AAD and would like to use these fields to add the employees into Organizations in the JSM projects. We use Organizations to track time per company as well as use the "share with your organization" feature.
Does anyone know if this is possible at all?
As it stands today, that's gonna a take quite a bit of work. I'm currently running a ServiceNow-to-JSM migration, and this is one of the blockers.
Atlassian Access doesn't support all the SCIM fields specified in RFC7643 . There is an open JAC request: ACCESS-657 
As far as what's supported today, these are:
These attributes are listed in the Get All Schemas  User Provisioning API endpoint. Map these in your user provisioning tab in Azure AD.
Okay, you've got your user data in Atlassian Access. What next? At this stage, you've only got the Get Profile  User Management API endpoint, and you can hover over a Jira User and choose "View Profile" to get this information.
In my case, because I couldn't load Manager information via SCIM, I had to resort to querying Okta directly via outgoing webhook automations to the Okta Users API and loading that information into Insight objects. You'll have to do the same, except with Organizations actions, and even then, I don't think it's possible to manipulate the organisation of JSM customers via automation. Be careful of hitting the rate limit if your trigger is "When object created" or "When value field changes for reporter", etc. You may be better off looking at Azure serverless functions to manage this, the JSM customers/organizations REST API is pretty good these days.
I'd like to see an Atlassian Access users and groups importer for Insight, and it'd be nice if they could make this data available to JQL, eg. project = ITSD and reporter in aql(department = IT)
Access Query Language, get it? Like if JQL met the SCIM protocol specification .
Thanks a lot for this comprehensive answer. With the capabilities in my organization and our willingness to build tools ourselves, I think it boils down to "No, that cannot be done".
I think it is unfortunate that Atlassian hasn't really implemented a proper way to import customers into JSM. As I see the current solution, it is basically just a side effect of importing users and not assigning licenses => user can be a customer because they are in the system. The entire use case of working with customer users in JSM is implemented very simply.
Eh, I've worked with a lot of worse service desks. If you're paying for Atlassian Access, it's worth your time to add the additional SCIM attributes.
I've never found the "organizations" to be that useful a feature for internal service desks. Users can share requests with team members, and they know their emails. It's a struggle enough to get staff to use an internal service desk, let alone get them to share the request with their colleagues. And auto-sharing with their team isn't very helpful, because their colleagues aren't really that interested in an individual's service requests.
As far as external companies go, Automation does have a nice "Convert email domain to organization" action. Just use that instead. Thanks for accepting the answer!
For JSM June Challenge #2, share how your non-technical teams like HR, legal, marketing, finance, and beyond started using Jira Service Management! Tell us: Did they ask to start using it or...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events