The question might be quite simple, but i cannot seem to get it working. How do I, on JSD Cloud, create a "portal only" customer without sending them an invitation email?
If i am in the user administraion interface i can invite users and there is the option to not send email verification.
So I created a few customer accounts by myself. But the full name of those accounts is the string before the @-sign. for example if the email is email@example.com, the user name would be mg. This does not look very nice. I would like to change that name but that does not seem possible.
in the user administration interface there is also a tier called "Jira service desk" in which "portal only customers" are listed. There i can change the names, but the accounts I have created are not shown there, even though i have not granted them product access.
I do not really understand that. Shouldn't they also be "portal only customers" if i have not granted them access?
How do I create a customer
- who does not have product access (not counting towards the licences)
- without sending an invitation/ confirmation email to that customer AND
- of whom I can set the display name?
I have already read some knowledge base article but i coundn't find any answers... I would be very glad for any help
Thanks for reaching out and while this is a seemingly simple question this one is actually really complicated as to why it is not possible, so I'm glad you asked for some clarification.
First though I can address the last point you listed with a simple answer which is unfortunately it is not currently avaliable for changing naming conventions, and some additional details can be seen in the following feature requests:
Next digging into the complicated portion relating to the notifications to Portal only users, there are some big blocker's and conflict points here relating to privacy and personal identifiable information (PII) exposure.
So this boils down to the simple answer of Sort of....... the No portion comes down to , Currently, it's not possible to disable the account invitation email and you cannot create an account for a Portal only customer without sending notice to that end user due to legal and compliance requirements on the application for this process.
However the sort of option opens up a workaround where you create the user as an internal account and remove their license to convert to a portal only account, or collect information via issue collector as a non portal user for manual interactions outside the portal, the process is outlined here:
BUT do note that doing this at some point the end user will get a email for account verification once interactions start with that users account in the service desk request.
There are some distinctions between internal managed accounts to be aware of allowing you to not send a notification to internal licensed accounts as mentioned above vs the required notification to the External Portal only customers, covered in section "2.3. End User Consent" of the "Atlassian Cloud Terms of Service"
And in Section "2.4 Responsibility for end users" noting the portion towards the bottom of 2.4:
We may display our User Notice to End Users at sign up, account creation, Cloud Product registration, or in-product. If you use single sign-on (SSO) for identity management of your Cloud Product(s) such that End Users will bypass these screens and our User Notice, you are responsible for displaying our User Notice to End Users and for any damages resulting from your failure to do so.
These user notices comes down to legal requirements on various compliances, where you must send a confirmation of account creation to the end user where their personal information is being used on the service where that user is not verified under previous precedence (such as employee contract for domain users signing into your local policies for email account usage within the organization) as you cannot use their personal email without express permission. In the Service desk portal only accounts these can be made public portals with organizational crossovers and there is no way to verify the account holders control of all accounts, therefore even if an internally verified user of a controlled domain becomes a customer that customer is created with or can be added to pools of users that may or may not be contained in that same managed identity management system and allows for an option of external visibility of PII requiring a end user verification.
The full official details on the requirements and definitions for the cloud accounts can be seen in the legal and security policies which can be reviewed at atlassian.com/trust and atlassian.com/legal
Looking at the Wrongful activities section of the "Acceptable Use Policy" it specifically notes:
- Using the services to violate the privacy of others, including publishing or posting other people's private and confidential information without their express permission, or collecting or gathering other people’s personal information (including account names or information) from our services
As one example on the definitions, the US department of labor defines personal identifiable information (PII) as:
Any representation of information that permits the identity of an individual to whom the information applies to be reasonably inferred by either direct or indirect means. Further, PII is defined as information: (i) that directly identifies an individual (e.g., name, address, social security number or other identifying number or code, telephone number, email address, etc.) or (ii) by which an agency intends to identify specific individuals in conjunction with other data elements, i.e., indirect identification. (These data elements may include a combination of gender, race, birth date, geographic indicator, and other descriptors). Additionally, information permitting the physical or online contacting of a specific individual is the same as personally identifiable information. This information can be maintained in either paper, electronic or other media.
So the Email addresses of an individual is consider as personal information and the notification of account creation is to provide a verification point that than account is allowed to be used in this system in the manner the requestor is providing and cannot be bypassed.
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event