Yes, we did get it sorted. Our Atlassian Cloud app registration within AzureAD was created a long time ago so it didn't have the correct appRoles for the provisioning to work. Our app only had the msiam_access role available, and not the "User" role. The User role is what is filtered on for the provisioning to work. We ended up patching our application registration using the graph api to include an additional appRole called User which then allowed the provisioning to start working once the User role was assigned to the users. 

@s.mahood did you get a response from Jira or Microsoft on the NotEffectivelyEntitled error. We have the same issue 

akilunov there is SCIM add-on available on Marketplace for Jira Server. Not sure it is Data Center compatible though but certainly works for Server.

Hi mharley1059103882, and alex.zia, I've emailed you with the hope that I could interview you and understand your setup and requirements better. Our support of SCIM is very new and we are actively looking for enhancements we should consider making; your input would be super valuable for us. – Best, Lingbo (Product manager for SCIM at Atlassian)

Hi akilunov, this ticket is only for Atlassian's cloud applications (Jira Software Cloud, Jira Service Desk Cloud, and Confluence Cloud, with support for Bitbucket Cloud and Trello coming in the future). We do not currently support SCIM provisioning with Atlassian's Server and Data Center products. However, these products do have several options for LDAP integration.

@Dave Meyer just to confirm - has this already been implemented for Okta in the latest Jira/Confluence Datacenter release? Or is it still in the pipeline?

Hi Dario. The issue isnt related to migrating from on prem to Cloud. It's moving from not using an identity provider for provisioning to using one.

PSCLOUD-20188 is the issue we have raised. Your colleague Claudiu is investigating.

There seems to be an issue whereby once a user account is created, there is a unique link to the Azure AD entry, even after completely removing all trace and starting again. We have a fundamental issue where duplicate accounts were created due to mismatching UPN and emails. We have a potential fix to this by changing the attributes in Azure AD for the Atlassian email field from mail to UPN but as the accounts are already created i fear this will only work for new accounts created moving forward. We have about 27 accounts that have managed to duplicate themselves because of this issue and, currently, have no way of resolving it.

reiss.snooks1831337561, the behavior you are describing reminds me of ID-6789. Can you let us know the ticket number you have submitted so that we can further look into this?

s.mahood please raise a support ticket in support.atlassian.com to have your issue further investigated.

We are having some strange issues as well. All our users are listed as NotEffectivelyEntitled if they are assigned to the application through the Users + Groups in AzureAD and the provisioning is set to sync only assigned users and groups. I've raised a ticket with Microsoft who have now passed it to the backend engineering team as they've confirmed that it's all configured correctly. 

There seems to be some strange issues with the AzureAD user provisioning. It appears it tries to sync accounts that failed even after they are no longer in scope to be synced anymore every 30 minutes. There are also issues with duplicate accounts being created if UPN doesn't match Email address. I've logged this with Atlassian but was told to raise it with MS