> Hi all,

> We have a new API available here: https://developer.atlassian.com/cloud/admin/organization/rest/api-group-users/#api-v1-orgs-orgid-users-search-post that returns the user email address regardless of profile visibility setting.

> Thanks,
> Stefan

If the Customer is not yet added to an org, but the customer is known to be a member of a particular org, how are we to add them to the org from the portal if we cannot see their email?

We cannot find this users email unless they are on an org, based on this request. 

Dear Customers, 

We have a new update regarding this feature and it can be tracked on this request:

• ID-77744 - Allow site admins to fetch email addresses when using the REST API endpoints to get all users
  Atlassian Update – 12 April 2024

  Hi all,

  We have a new API available here: https://developer.atlassian.com/cloud/admin/organization/rest/api-group-users/#api-v1-orgs-orgid-users-search-post that returns the user email address regardless of profile visibility setting.

  Thanks,
  Stefan

Thanks,
Hala | Atlassian Support Team

I have the exactly same issue as Kirstin.

Users having two accounts, one that worked fine when they were accessing only portal, but when we started collaborate more, added them into confluence for documentation collaboration, then we now see 2 accounts in Organizations. The original portal only with email address visible - hence added to organization where they need to be. The other is the 'full account! with confluence access but in service management show as "private email" and cannot then be added to organizations.

When they log in to portal seems the full account gets prioritized and they can never use the portal only again.

My suggestion would be to let us add Customers to organization without having to match their email. (Just add an option in the customers menu to add that customer to an organization with an organization dropdown, for example) Then their mail can remain "private".

We migrated to cloud recently, and due to this issue we now have the following problem in our customer support:

• Customers sign up hiding their email address.
• We want to add them to their organization but this is not possible. You need to enter the email address of the customer you want to add.

As a consequence, we have to ask them to change their settings to expose their email to the public to be able to add them. To me, this seems kind of unprofessional.

This constraint has caused us yet another hiccup in our Cloud migration project. We have hundreds of duplicate accounts that we can't merge (see related Jira issues ID-240). We need to identify these duplicates prior to migration. But currently this is a long-winded process using the API. Please provide this information on the Org Admin API for non-managed accounts.

This needs to be fixed with a high priority.   It is putting a major wrench in the gears of our migration to the Cloud, compared to what we have with Jira Server-

The premise:

For orgs that are paying the extra fee for Atlassian Access, and have claimed the accounts under their email domain, it needs to be in the orgs admins control as to how email addresses and other identifying factors are managed, not Atlassian. 

The GDPR argument:

The whole point of paying for Atlassian access is not just to enable SSO, it is to perform identity access management (IAM).  This means having visibility to who the account is, and be able to systematically verify that the account performing actions in your Jira instance is the same account as in your Azure Active directory (or other provider).   The IAM functions in Atlassian Access need to allow for a company to decide what is visible where.    Using the GBPR cover for this decision does not apply to managed accounts, and is an over–interpretation of GDPR.  Companies with an explicit business purpose (security & compliance) can per GDPR legislation use a company provided (=managed account) for business purposes.  Private and/or non-company provided emails are of course subject to GDPR, but that is a different subject altogether, and should be a seperate debate.

The legal/regulatory/ audit requirement:

It is not an option for many companies such as ours to not manage access to their systems.  The requirement is a lot more than just a once a month dump of accounts, and checking who they are.   It is among other things about cross application Segregation of Duties (SoD): to be able to check the event by event activity of that account against company defined segregation of duties and approval levels that our company is legally obligated to adhere to, and prove to external auditors/ regulators.  There are a whole host of regulatory agencies in several countries that would shut us down if we could not prove who did what, and that regulations were followed.  When using Azure AD and SSO, the email prefix is the same as the AD account, and is the unique identifier across all applications in the company.  At a bare minimum we need access to the same info we have/had access to in Jira Server: the AD / SSO account (email prefix).

The current (very bad) workaround:

In order to pull compliance data via the APIs, the service accounts that could do the same thing with Server using only browse users permissions, now need to be allocated the Org Admin permissions.   Org admin is a "Critical access level", and requires logging and additional auditing to ensure the account used for this only did this and not other things.

Even within workflows, to register and send to other applications the AD account info of the person executing the workflow transition requires a lot of funky workarounds, that I am not sure how the auditors will react to. 

The clear fix is for Atlassian Access customers to be able to do IAM, like the sales material alludes to.      

This does not work, in some cases, even when the user does not restrict the email visibility. It is a bug, please fix it. 

Bump. We have billing systems which grab active user emails using the Org API and use these emails to cross reference and grab their internal billing details. We have now realised this system does not work for non-managed accounts which causes a huge problem. Why is this the case when you can easily grab the email through the UI? What does the removal of this feature from the API achieve?

I want to help to bump this up. I am a enterprise user and currently moving my instances from several Org Admins to one.

Currently we are moving our instances and placing them in one Org admin but this is limitation of not be able to get the users emails is a huge issue, specially when we need to perform audit in the system. We cannot release Org Admin tokens to users for the simply reason of security.

Also, we have managed and non-managed users. Been an administrator, it is a huge audit flaw to depend of the user goodwill to make the email public so the administrator of the product/ instance can see and collect the data. (which is a direct conflict of concepts, I can see all the information inside the admin panel but can't query via API...)

Atlassian can add an API to export or list all users with email in Org APIs,  so Org admins can scan or check users automatically.

in large enterprises we need the feature to check users to satisfy the security policy and compliance.