nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How does one deal with deactivated Atlassian accounts preventing creation of JSM customer accounts?

Rick Westbrock

We have run into a scenario where a few users who had Atlassian cloud accounts in order to use Jira but later changed to a different job within the company which does not require using Jira so we deactivated their SCIM provisioned accounts. The problem is that my automated customer maintenance script is unable to create a JSM customer account with their e-mail address since it matches the deactivated Atlassian account.

We had run into this in the past for terminated users because e-mail addresses can be reused and in those cases we just delete the deactivated Atlassian account which allows the script to create a customer account. The current scenario would require that I contact the former manager of the transferred users to find out if it's okay that the Assignee field and comments will show "Former User" once we delete the Atlassian cloud accounts.

Has anyone else run into this scenario and if so how did you deal with it?

Accepted answers

Jean Horn_0wd0b5

👋Hi @Rick Westbrock ,

I understand you use an account provider, but in the scenario you presented, wouldn't it be more practical to remove the user's license instead of deactivating/deleting their account? This way, it won't affect the work previously done by that account.

In the future, if this user needs to access it again, they can simply add the license again.

What do you think about this? Would it make sense for you to work this way? ~ 😀

Best Regards,

Jean Horn

All comments

Jean Horn_0wd0b5

👋Hi @Rick Westbrock ,

In the future, if this user needs to access it again, they can simply add the license again.

What do you think about this? Would it make sense for you to work this way? ~ 😀

Best Regards,

Jean Horn

Rick Westbrock

That would work except that it conflicts with our SCIM provisioning process. In order to allow the service desk team to provision Jira access the IDP group for Jira users is pushed to the Atlassian directory and that group is granted Jira access (aka license) so currently in this scenario the service desk removes the user from the IDP group which deactivates the Atlassian account.

The process was designed this way so that my admin team doesn't have to be involved in simple user account provisioning. Your idea has merit though and we might have to refactor our provisioning process so the IDP group doesn't grant any licenses which would allow us to remove Jira access without deactivating the account. That will likely require that I build a parallel provisioning process where the service desk can use a different tool to add & remove users from the group which grants the license so that my team still does not have to be involved in basic provisioning.

Jean Horn_0wd0b5

I understand that this type of control using SCIM can be a bit of a headache in the context of Atlassian accounts, since deleting a user's account can affect the user's completed work.

I found a ticket with a subject related to your problem, you can check it through this link.

Bob Dalm_tujfdy

@Rick Westbrock - ideally, the provisioning group is separate from the license group. Easiest solution would be that on IDP level an additional group is added for license, which gets removed when a user no longer need Jira (user) access.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-service-management-cloud

jira-service-management