Dave Meyer Atlassian Team

@Geert Peter what are you trying to do? It sounds like you are trying to remove yourself as an administrator?

That's correct, only the 25 agents would be billable assuming you're using Jira Service Management customer accounts for the remaining users.

@Geert Peter it's important to understand that Atlassian accounts in cloud are "global" – they don't belong to any individual instance. This means that the corporate IT department (as defined by the email address of the user's account) has ultimate control over the account.

Hi Marco, There are more details on how the Access bill is calculated here: https://support.atlassian.com/subscriptions-and-billing/docs/manage-your-bill-for-atlassian-access/ Cheers, Dave

Hi @Alex Dillon , I would recommend contacting Atlassian Support. They can help verify your account access and get access to your account. https://support.atlassian.com/contact/ Dave

Hi Hendrik, We don't currently support the ability to completely block users from accessing any product. We're evaluating whether this is something we will support in the future. https://jira.atlassian.com/browse/ACCESS-571 If you have the capability on your networking side, you can always block access to the trello.com…

Hi @Alexis Robert , I just wanted to jump in and clarify that while we are committed to expanding access to data residency beyond the Enterprise plan this year, we have not yet finalized publicly the availability and timing. Rest assured we are working to announce more details as soon as we can. Cheers, Dave

Hi @Gary Bucher , Yes, check out the documentation for user provisioning, which is a feature of Atlassian Access. User provisioning allows you to sync groups that are managed in your external identity provider (like Azure AD, Okta, Onelogin, and others). These groups are then made available in all sites that are linked to…

Agreed. If the user has already been invited manually and you assign a user with the same email address in Okta, then we will match it to the existing account. The profile details from Okta will become the source of truth and the user will be fully managed in Okta like any other IdP-managed user. On the end user's side,…

Hi Jeffrey, I reviewed this with our engineering team, hopefully these instructions make a little more sense: * Users created through user provisioning will have two associated ids: id and an Atlassian account id.* Id refers to the user id in the user provisioning directory and is used by the identity provider to update…

Hey @jbartlett86 , yep confirming your summary is correct. Definitely understand that the design is not ideal for use cases like the one you described. One mitigating factor is that for situation #2, where the betacorp.com users are logging in with Atlassian accounts and don't have SSO enforced, is that we do support…

Hi @jbartlett86 , A key difference between our on-premises products and our cloud products is that in the cloud, each user has a single Atlassian account tied to their email address that is used for all products and all tenants. The benefits for users are significant: * You have a single username/password (or SSO provider)…

Hi @nicolas.gavard , Atlassian's SSO offering with Atlassian Access is tied to your company's email domain, so when you set up SSO, it will be applied to all users that are using their professional email (that your company manages). SSO is enforced on the account, so it will be applied whether the user is using your…

Hi @nicolas.gavard , The behavior you're describing is a little bit surprising. When you set up SSO with Atlassian Access, the authentication is for the users' accounts themeselves. The individual Jira instance that your employees are using with the subcontractant should not know that they are authenticating with SSO at…

Hi @Nitinkumar Balar , you can contact support via support.atlassian.com using your Atlassian Access SEN.

Hi @Nitinkumar Balar It sounds like you've already provisioned separate Atlassian accounts from G Suite under your organization's email domain, while everyone still has all their data under their personal accounts. Unfortunately it's not possible to merge accounts yet, so what I would recommend, assuming your team hasn't…

Interesting. I think that the `account_id` attribute that you'll get from this API (https://developer.atlassian.com/cloud/admin/organization/rest/api-group-orgs/#api-orgs-orgid-users-get) will be the correct id, but I wasn't able to test it to verify. Note that that API takes a different token than the SCIM API 

Hi @Jeffrey Anderson , Sorry for the delay in getting back to you. I think the value should be the `id` in the Get all users method https://developer.atlassian.com/cloud/admin/user-provisioning/rest/api-group-users/#api-scim-directory-directoryid-users-get

Hey @Jeffrey Anderson , If you sync a group via the SCIM API with a user that has the same email address as an existing managed account, the profile details from the SCIM push will overwrite the existing profile attributes of the account, and the account will be treated as managed externally and they will have membership…

Hey @David Hawn , There's no requirement that you have to use Atlassian's G Suite integration to verify your domain. The setup for your scenario should be pretty simple: 1. Use the DNS or HTTPS verification methods to verify your domain. 2. Configure SSO with your 3rd party IdP in Atlassian Access. In order to use the DNS…

Hi @Jeffrey Anderson , You can use our SCIM API to send group information and updates and have them synced to Atlassian (and groups will be synced to your Confluence site assuming it's linked to your organization with Atlassian Access). Check out: https://confluence.atlassian.com/cloud/user-provisioning-959305316.html…

@Prince Nyeche - ELFAPP @sam saas Thanks both for your clarifications, I understand the confusion now. I think the error is that this shouldn't be listed as a public API in our documentation – the only place I'm aware of where we present the data that this API endpoint returns is when you land directly on…

@sam saas Admin API keys are scoped to a single organization (they can be used by multiple users since they are owned by the organization, not any individual user). That said, most administrators only administer a single organization, since an organization is typically mapped to a company, and most people only work for a…

@Prince Nyeche - ELFAPP can you double-check whether you're using a personal API token (tied to your Atlassian account) or an Admin API key (which is associated to an organization and must be created by an organization admin). You're correct that a personal API token should work across all products you have access to, but…

Hi @Bert deRoos , verify the domain we're working for, in our case exampleenterprises.tld. Verifying this domain enable the possibility in Atlassian Access to setup SSO integration with Okta Correct Users from exampleenterprises.tld and ibm.com (e.g. john.doe.xyz@ibm.com), authenticated by Okta, should have access to…

This is correct. Atlassian accounts can be used across multiple cloud tenants, so SSO is tied to the organization that owns the account. In this example, IBM would own @Inessa B.com accounts, and those accounts would authenticate with IBM's identity provider (Okta or an equivalent). We are currently working on support…

Hi @Jeffrey Anderson , Check out the recommended attribute mappings here https://confluence.atlassian.com/cloud/saml-single-sign-on-943953302.html#SAMLsinglesign-on-1.AddtheAtlassianproducttoyouridentityprovider

Hi @June , If you are using a Google account as an Atlassian account, you should simply enable two-step verification on your organization's Google accounts: https://support.google.com/a/answer/9176657?hl=en An Atlassian Access subscription would still be required to enforce that all users log in via Google…

Hi @Jason Li Ting Chung , Only SAML SSO is supported with AD FS. Our SAML implementation supports just-in-time provisioning, but AD FS does not support user provisioning via the indstury-standard SCIM protocol. To set up user provisioning, you will need to connect AD to a cloud identity provider like Azure AD. See…

Hi @David Norman , I looked at the open bugs for Access and there was nothing resembling this issue. This is a very common SCIM operation so if there was a bug causing this, it's likely that it would be reported. There may be an issue with your Okta provisioning configuration (there are instructions in the setup docs for…