Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
badges earned

Your Points Tracker
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Add customers to organization based on data from Azure AD

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?

1 answer

1 accepted

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!






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.

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!

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.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published in Jira Service Management

JSM June Challenge #2: Share how your business teams became ITSM rockstars

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...

172 views 6 7
Read article

Community Events

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

Events near you