Add customers to organization based on data from Azure AD

[Jens]

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?

[Alex van Vucht (GLiNTECH) · Accepted solution]

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 [1]. There is an open JAC request: ACCESS-657 [2]

As far as what's supported today, these are:

• userName
• name.formatted
• name.familyName
• name.givenName
• name.middleName
• name.honorificPrefix
• name.honorificSuffix
• displayName
• nickName
• title
• preferredLanguage
• timezone
• active
• emails[type eq "work"].value
• emails[type eq "other"].value
• phoneNumbers[type eq "work"].value
• phoneNumbers[type eq "mobile"].value
• urn:ietf:params:scim:schemas:extension:enterprise:2.0:User.department
• urn:ietf:params:scim:schemas:extension:enterprise:2.0:User.organization

These attributes are listed in the Get All Schemas [3] 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 [4] 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 [5].

Good luck!

[1] https://datatracker.ietf.org/doc/html/rfc7643

[2] https://jira.atlassian.com/browse/ACCESS-657

[3] https://developer.atlassian.com/cloud/admin/user-provisioning/rest/api-group-schemas/#api-scim-directory-directoryid-schemas-get 

[4] https://developer.atlassian.com/cloud/admin/user-management/rest/api-group-users/#api-users-account-id-manage-profile-get 

[5] https://tools.ietf.org/html/rfc7644#section-3.4.2.2 

[Jens]

Hi Alex

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.

[Alex van Vucht (GLiNTECH)]

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!

[Jens]

Thanks for the tip about the automation. We do have external people in our system as well as internal employees.

Our main use for organizations is to be able to account for where our time is spent.