Automatically add trusted domain employees via email requests

[Ron W]

Hi,

I am trying to configure a specific user setup in my Jira/Atlassisan IT Service Management project/space and have had little success after following numerous guides and steps. I'm hoping someone can help me to achieve my goals:

- I would like 4 paid "agents", including myself, who will be managing and handling IT requests as they come in. I've already purchased these. Ideally, I would like these users to login via SSO to my iDP (Microsoft Entra). I've purchased Atlassian Guard licenses for this as well, however, I am concerned that by adding my verified domain to this Auth Policy, I may not be able to assign internal/trusted employees properly (see below requirements). I do NOT need SSO and can scrap it if needed.

- I would like all internal employees to have the ability to email in a service request.

- I have our company domain added as an approved domain, and as long as employees are emailing from this domain, I would like them to AUTOMATICALLY become a user (managed/unmanaged? or customer? I'm not sure I fully understand the difference) when they email in with a service request. I also would like employees to be able to CC any other employee(s), which would authorize & add the CCed employee(s) as part of the ticket and a user in the space/project as well.

- The internal users/customers do not need paid licenses. I simply want them to have permissions to email a Service Request into my project/space, as well as reply to Service Request comments, etc.. I do not even need them to login to the Portal (I may want this in the future, though). They can be users, or managed accounts that get claimed by the trusted domain, or Customers. Again, not positive on which one of these makes most sense for me, that is part of this inquiry. Ideally, they should NOT have to verify their account, or accept an invite, that way this is all transparent to internal employees, once I go live with my Jira ITSM. I would like these employees to organically get added into the system, as they email in requests. 

- Some of the Service Requests that come in will require approval. I need to be able to assign some users to Approver Groups - as of now, I only see the option to assign a Paid User to a group - I don't seem to have the option to assign Managed Accounts or Customers. These "approvers" will receive Approve/Deny emails through the Approval Process workflow. Again, no need for them to login, they simply need to Approve/Deny, as well as submit/respond to tickets, all by email.

Here are a few things I've done, that in theory would accomplish the above but don't seem to be doing as expected:

- Project/Space Settings > Customer permissions > Channel Access is set to "Open", and Customer sharing is set to "Customers can search for other customers, or manually enter the email address of other customers within their space."

- Jira Service Management > Settings > Email requests > Checked "Anyone can create new accounts based on customer access and space level customer permissions settings"

- Jira Service Management > Settings > Customer access > In Internal, checked "Use approved domains", added our company domain. In External, checked "Allow portal-only accounts...", and "Only allow... with specific domains", and added the company domain. In Portal Access, checked "Allow customers to create accounts".

- Jira Service Management > Settings > Organizations > Created a company Organization, and added our company domain, hoping this would automatically add new email request users as Customers, as per Jira documentation. 

With the above settings, when an internal employee sends in a request for the first time, they get added as a "Managed User" that's Unverified, and the receive an email to Verify their account - and their email does NOT generate a new Service Request, seemingly because they are not "verified". As stated above, I would like them to auto-verify as non-billable users/customers as soon as they email in, and I would like their email to generate a new Service Request / ticket.

Thank you very much in advance to anyone that can help!

-Ron W

[Marc -Devoteam-]

Hi @Ron W 

Welcome to the community.

- I would like 4 paid "agents", including myself, who will be managing and handling IT requests as they come in. I've already purchased these. Ideally, I would like these users to login via SSO to my iDP (Microsoft Entra). I've purchased Atlassian Guard licenses for this as well, however, I am concerned that by adding my verified domain to this Auth Policy, I may not be able to assign internal/trusted employees properly (see below requirements). I do NOT need SSO and can scrap it if needed.

"Hi you can decide what permissions you grant users in the administration. See also the App access setting option in the Atlassian administration of your instance"

- I would like all internal employees to have the ability to email in a service request.

"Make sure a request type is linked to the default email, see Email option in project settings and set the customer permissions correct, or add the group containing all company users (synced via SSO integration) to the role Service Desk Customer in the project (then any new added user in the IDP will get access by default)"

- I have our company domain added as an approved domain, and as long as employees are emailing from this domain, I would like them to AUTOMATICALLY become a user (managed/unmanaged? or customer? I'm not sure I fully understand the difference) when they email in with a service request. I also would like employees to be able to CC any other employee(s), which would authorize & add the CCed employee(s) as part of the ticket and a user in the space/project as well.

"See above, not needed on IDP integration and correct setting of the customer permissions and/or role on the project"

- The internal users/customers do not need paid licenses. I simply want them to have permissions to email a Service Request into my project/space, as well as reply to Service Request comments, etc.. I do not even need them to login to the Portal (I may want this in the future, though). They can be users, or managed accounts that get claimed by the trusted domain, or Customers. Again, not positive on which one of these makes most sense for me, that is part of this inquiry. Ideally, they should NOT have to verify their account, or accept an invite, that way this is all transparent to internal employees, once I go live with my Jira ITSM. I would like these employees to organically get added into the system, as they email in requests.

"Done by granting the the group (from SSO IDP integration,  the Customer permission. No account verification would be needed"

- Some of the Service Requests that come in will require approval. I need to be able to assign some users to Approver Groups - as of now, I only see the option to assign a Paid User to a group - I don't seem to have the option to assign Managed Accounts or Customers. These "approvers" will receive Approve/Deny emails through the Approval Process workflow. Again, no need for them to login, they simply need to Approve/Deny, as well as submit/respond to tickets, all by email.

"Any user with customer permission on the JSM project can be set as approver."

[Ron W]

Hi @Marc -Devoteam- 

Thank you very much for the response!

I believe you're suggesting that by integrating my IDP with my Jira instance, I can sync a group from my IDP and that will solve the bulk of my issues. But in order to do so, if I'm not mistaken, I would need to purchase the Atlassian Guard license for each users in order to integrate with my IDP, and then sync them over. We have close to 1000 users and so that can get very, very costly. Is there a way to accomplish my goals without requiring a paid Guard license for every user?

Thanks again

Ron W

[Marc -Devoteam-]

Hi @Ron W 

No you will need Atlassian Guard for this, if you want to manage your users and have SSO in place.

If you don't want an IDP integration, you can only invite users.

User who sent an email, will be ome a user in the system, but users in CC not.

Users in CC will be listed as request participants, they could create their own account if you permit this, so they can see the requests they are set as request participant