In case anyone else is looking I found this ticket for requesting API management - https://jira.atlassian.com/browse/JSDCLOUD-14251

+1 to Clemens' comment.

I can see the new global "Organizations" screen under "Settings > Products," but I don't yet see the option to add email domains to any of our existing Orgs.

Should this feature be available for everyone now or for just a few selected Spaces?

Hello, what about JSM Datacenter?

We tried workaround and have had some issues.  This is an imminent requirement for us that is delaying deployment of JSM to major groups in our company.  Would like to be part of early test / adoption group.

We added the workaround automation rule but have been seeing some weird results similar to Diana's comment...

Some organisations were setup before we added the rule. E.g. "ACME Company Ltd", "Some Other Company Plc." etc.

Now for certain users (we've observed the behaviour with a few members of staff who have a service desk license), when they raise a ticket, they are being assigned to an existing org but it's not clear how the matching is done since orgs don't have an associated domain. Even if we remove them from the organisation, they get re-added when submitting new tickets.

Example:

ServiceDeskAgent1@OurCompany.com raises a ticket and the automation rule assigns them and the ticket to "ACME Company Ltd".

We delete them from "ACME Company Ltd" but when ServiceDeskAgent1@OurCompany.com submits another ticket, they get re-added again and the ticket is auto-associated to the same org.

My guess as to how it's working is this... After the automation rule is added and enabled, a customer raising a ticket will be added to a pre-existing org if they or someone else with the same domain name is an existing customer of an existing org or has ever been a customer of that org. If there are no existing customers with the same domain then a new org will be created. Thereafter, any requests from customers with that same domain will be added to that new org. It doesn't seem possible at the moment to remove customers from orgs because they are always re-associated.

I would be very interested in testing this as soon as possible

As a heads up to anyone who may be interested in using the Automation workaround provided back in December, I did some testing of it and here are my findings:

• If a customer is part of a manually created org, they will be auto-added to a new org created by the automation based on their email domain
• We can rename the automatically created org without issue – users with the same email domain will continue to be auto-added to it
• There is no indication anywhere inside the org setup in the JSM project that there's an email domain tied to it, so we can't see which orgs are being "maintained" by the automation vs those that aren't
• If a user is manually removed from an automatically created org, they will be automatically added back the next time they log a ticket, based on their email domain
• If a user selects "Share with No one" in the Service Desk when logging a ticket, the automation will override the selection and apply their email domain-based org to the ticket, making the ticket visible to everyone in that org against the user's wishes

Would like to participate in the EAP once available for this

How is it possible to sign for EAP?

Hello!
We would need this feature too, to give restricted portal access only to the specific domains, because we have several external service projects.
Do you have an ETA that we can look forward to?

Happy to test this feature. 
I hope it's going to work if we have enabled public signup for customers and have disabled ticket creation / follow up via email?

Hello!

If possible, I would also like to participate in early access

Thanks!

Hi @Benjamin Paton

Would it be possible to participate in the early access testing for this one? 

Thanks!

Hi Jira,

This is really needed.
Lots of manual work now.See how many customers this need.

Stop considering and start create a User Story from CHATGPT.  

Early access for our organization would be great, so feel free to contact me!

I need to clone the organization field to Jira Software. From what I can see, organization field is not available Jira Software. I might be wrong, but I guess cloning organization field to Jira Software will not work as long as organization field is not available in Jira Software. 

 I am interested in early access to this feature when it's ready.

I am interested in early access. 

I am interested in early access as well

Hi. Is there any update on this at all please? Last I saw was implementation for 2024... any approximate ETA at all?

Hi

This will be a good option - Also can you create a person to an existing organisation.

a1217920d496 I am interested in participating in early access for Email domain organization association.
 

I would also be interested in early access please

Would love to be a part of the EAP or Beta for this feature, please.

@1217920d496  @ Ash Young Also interested in early access! We have a '1 to n relation' of organziations to domains. 

A great update and one we've looked forward to for a very long time. Thanks Ash!

a1217920d496 I am interested in participating in early access for Email domain organization association.

a1217920d496, 
Also interested in early access to this. I manage 30-40 domains and need so tag requests between them. 

Any update? It is 2412 days from the start 

Hi a1217920d496 @Ash Young,

We'd like to participate in the EAP.

I came here based on a comment @Benjamin Paton made on this community post: https://community.atlassian.com/t5/Jira-Service-Management-articles/Use-email-domains-to-restrict-external-customer-sign-up-for-your/ba-p/2036372

We have the following use cases:

1. One service project for internal users (our internal IT user help desk) – this works fine
2. One service project for specific named external customers, where we provide key-user support; we add them manually to the project with their email; access is restriced to those customers and sign-up is disabled.
3. Several service projects for external customers from specific domains, where we provide end-user support; we don't know those users in advance and we cannot add them manually as there would be hundreds of them; we do however know their email domains.

Our issue is with case 3: For those projects, we would have to allow for self-signup – but only from specific domains that are connected to specific organizations. Currently, domain restrictions can only be set up on a global level, with no connection to a specific service project.

G'day @Ash Young, we too would like to participate in this.

Just after some clarity after the new 'Customer' role and the whole internal/external/hybrid matter, does this domain feature only apply to internal customers (as in, product access role), or does it also apply to portal-only customers (external)?

Thanks,

Rob

What's the ETA on this? seems like a pretty simple fix: 'if' the user (new signup for example) has a domain which matches the domain added to an organization (add admin ability to add domain to organization), then add the user to the organization. This will then allow the user to see the portals which the org is assigned to.

@ash young,

We would like to participate in early access.  We manage 6 domains and really need this!

a1217920d496 I am interested in participating in early access for Email domain organization association.

a1217920d496 I am interested in participating in early access for Email domain organization association.

It would be super interesting to also contemplate the tickets that are created via Slack, to associate these, depending on the channel they come from, to one or another org.

Would love to be able to have early test access here

Hello a1217920d496 ( @Ash Young )

We would like to participate as testers as well.

Thanks

Hi Team,

We would like to participate in this pilot.

a1217920d496 we would be super interested in testing this feature. 

a1217920d496 , we would be very happy to particpate in testing this feature.

a1217920d496 if this is possible, please add me to the testers

@Ash Young we would like to participate with this testing if possible? We're current testing Jira Service Management with a view to transfer away from Zendesk within the coming months. This would be extremely useful for us without the need to script a process using the API.

We would like to participate to this test. We're about to go live with JMS and this feature is vital

We would also like to see this developed and would be happy to test it for you.

@a1217920d496  We would like to participate in the feature testing.

@a1217920d496  I would also like to participate in the feature testing. 

We would love to be a part of this feature testing !!!

We would love to join beta/user testing for this feature @Ash young