Uploaded image for project: 'Atlassian Guard'
  1. Atlassian Guard
  2. ACCESS-865

Don't delete the SCIM directory when Access subscription is revoked.

    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      Problem Definition

      Currently, when Atlassian Access subscription is not automatically renewed due to payment issues, the user provisioning directory is deleted. The groups that were being synced become Jira internal groups to preserve the access the users have to the site (when that is configured for the synced groups by adding them to the default product access) and so that they can be editable on the application.

      This causes a huge impact for the system administrators that needs to reenable that integration again as there is a limitation where you can't sync groups with the same name. Beyond that, some IdPs keep a reference for the old users' ids demanding a cleanup on their end.

      Suggested Solutions

      Create a mechanism to keep that directory information that requires a manual deletion from the Org admins to reduce the steps needed to make that integration working again.

            [ACCESS-865] Don't delete the SCIM directory when Access subscription is revoked.

            Please implement this- at least for customers where access is revoked due to delays in payment. There are a number of factors that can slow down payment time (AP processing, vacation time). 

             

            We recently spent over 5 hours (3.5 of these with an Atlassian support agent) rebuilding our Atlassian application in OKTA. With a userbase of over 2,500 employees, this was a nerve racking experience that could have been completely avoided. 

            Reid Bourgeois added a comment - Please implement this- at least for customers where access is revoked due to delays in payment. There are a number of factors that can slow down payment time (AP processing, vacation time).    We recently spent over 5 hours (3.5 of these with an Atlassian support agent) rebuilding our Atlassian application in OKTA. With a userbase of over 2,500 employees, this was a nerve racking experience that could have been completely avoided. 

            We've shipped the capability to sync IDP groups with the same name as the site groups - https://confluence.atlassian.com/cloud/resolve-group-conflicts-before-syncing-users-1014677306.html

            Narmada Jayasankar added a comment - We've shipped the capability to sync IDP groups with the same name as the site groups -  https://confluence.atlassian.com/cloud/resolve-group-conflicts-before-syncing-users-1014677306.html

            Okta Admin added a comment -

            We are experiencing this issue right now and I wonder if there is workaround where support can restore the deleted Directory because we have the directory ID we used when our Access Subscription expired and we had an expired card so billing didn't go through. We need this restored because as the ticket mentions our IDP(Okta) will not sync anymore and new user provisioning is failing.

            Okta Admin added a comment - We are experiencing this issue right now and I wonder if there is workaround where support can restore the deleted Directory because we have the directory ID we used when our Access Subscription expired and we had an expired card so billing didn't go through. We need this restored because as the ticket mentions our IDP(Okta) will not sync anymore and new user provisioning is failing.

              Unassigned Unassigned
              jnunes@atlassian.com João Nunes
              Votes:
              0 Vote for this issue
              Watchers:
              9 Start watching this issue

                Created:
                Updated:
                Resolved: