Allow our internal work domain (only) to get to portal and send requests via email

[Doug Nelson]

We're looking to use JSM for our helpdesk for our work domain only, for internal support. 

Let's say we are @Work.com as the domain.

Anyone who sends an email to our support email (associated with the jsm project/portal) should have their issue received and should get a reply. We have manufacturing folks and the only thing they can barely do is send email; I can't ask them to go setup a Jira login just to be able to send email requests.

Conversely, those who want to use the portal should just be able to get access. It should still recognize them as them (via their email/domain account), but I want the number of steps to be minimal. 

We were trying this without SSO (to ms365) by setting the allowed domains and such, but it just doesn't work - if you don't setup the account, you can't send the email. And to set up the account is like a dozen steps and it would break the souls of many of our users.

Looking for a quick set of steps vs getting sent all over Jira, in and out of the project, to get this setup via articles and such I've found. If SSO is the 'only' way to make it work then I will have to buckle up and go down that road. 

Thank you

[Doug Nelson]

I guess those are in the ballpark of what I'm looking for, but imagine if you will that there was no portal (it's not a factor in what I'm after - other than as some artificial restriction perhaps). I just want emails to go in and out of the system for anyone included by someone with a valid account in JSM for the project. I know it sounds easier than it is, but seems like a basic functionality for internal helpdesks where a vendor/partner may need to be part of a conversation.

Also, those links look ignored. Has JSM development ceased for the most part?

[Bruna Silva]

@Doug Nelson you can find our policy on how we prioritize feature and improvement requests on the following page:

• Implementation of New Features Policy

In addition, we provide a public page to inform what's coming soon and what we're thinking about for future updates:

• Cloud Roadmap

Besides our roadmap, we have a blog post with all the updates involving the cloud products:

• Atlassian Cloud Documentation blog posts

[Doug Nelson]

Thanks Bruna - I want to make sure I'm clear regarding what you're saying and what I want. 

I don't want non-work.com (external) people to create tickets, I just need them to be notified of all communications in the Reply to Customer spectrum if they were added to an email used to generate a ticket by a work.com user (who will be in our system). These external people are basically 'cc'd' individuals who should see the back and forth but nothing else, just as if they were on an email stream. They shouldn't need to sign up for anything; just read their email to keep up.

I'm thinking you're saying it's not possible. So what I next want to settle for is having anyone being able to send an email to my email handles (support@work.com) and have the create a ticket, but not allow any communcation (notification), nor portal access, unless they are work.com employees.

[Bruna Silva]

Hi @Doug Nelson

Currently, customers need to have an account and portal access to be added as Request participants and interact with the service request. Thus, as soon as they are added as customers, they will be able to create tickets in the projects they have access.

An alternative for this scenario would be to create an automation rule to auto-close/deny requests sent from non-internal domains. If that sounds like a good alternative for your use case, you can create the automation rule by following the steps below:

1. Go to Project settings > Automation > Create rule
2. As Trigger, select Issue created > Next
3. Select IF: Add a condition > {{smart values}} condition
4. In the First value, enter {{issue.reporter.emailAddress}} > In condition, select 'does not contain' > In the Second value, enter your internal domain (ie. @work.com) > Next
5. Select THEN: Add an action > Choose the desired actions, for example:
   • You can use the Send email action to send an email to the reporter that this channel should not be used for submitting the request.
   • You can use the Transition issue to transition the ticket to a final status. Just note that to transition a ticket between statuses using automation, the transition between those statuses has to exist in the workflow.

Please note:

• This workaround depends on the user's email address visibility. You can see more details about it in this document:
  • How to display the email address of the reporter on a Jira Issue
• The above alternative will count towards your automation execution limit:
  • How is my usage calculated?
• Since it's a workaround, the behavior can change anytime.

[Bruna Silva]

Hello @Doug Nelson,

Thank you for reaching out to Atlassian Community!

Allow me to share with you that, currently, the customer access to a customer service project is set in the following pages:

Global customer permissions(affects all the service projects):

• From the top right of your screen, select Settings in the top right of the screen > Products > Under Jira Service Management, select Customer access

On the Customer access page, we can configure how new accounts are created, between Internal (Atlassian account) and External (Portal-only account) customers.

Please note that by using Internal accounts, when the user sends an email request for the first time, they will have to create their Atlassian Account. Thus, the customer will receive an email to verify their account and complete the signup before their request is created within your project. You can see more details about it in this document: Incoming email status - CONDITION PENDING.

Project customer permissions(affects only the service project):

• For Company-managed projects: From your service project, go to Project settings > Customer permissions
• For Team-managed projects: From your service project, go to Project settings > Channels > Customer permissions

More details about these permissions can be found in the following document:

• Permissions for your service project and Jira site

If you have any other questions regarding this matter, please let us know.

[Doug Nelson]

I'm generally aware of where all the setting are and mostly what they do, but what I don't understand is the combination of settings to get what I want JSM to do. And maybe it's not possible.

My work.com users should be able to either:

* send an email to create a ticket - and get updates, notifications, etc.

* create a ticket on the portal - and get updates, notifications, etc.

I want non-work.com people to be possible 'participants' on tickets, with my primary use-case being that they are cc'd on emails that are sent to our JSM support email. They should show up as 'request participants' (I figure) and be able to participate on the conversations via email but not be able to access the portal or create tickets through email on their own. I 'may' be willing to loosen up the rules for the last piece but would prefer to avoid spam and such and only have work.com accompanying emails create tickets.

I cannot be the first person that ever wanted this scenario, so someone has it working and can share the steps - or can tell me I'm screwed and that there's no way to make it work.

thank you

[Bruna Silva]

Hey @Doug Nelson

Regarding your question, at the moment, customers need to have an account and portal access to be added as Request participants and interact with the service request. For now, it's not possible to restrict their ability to create tickets while still allowing them to be Request participants.

However, we have open feature requests to have more customer permission options, as we can see below:

• More flexible portal-specific customer signup
• Ability to set domain restriction for private Service Desk to allow self-sign up

Please, feel free to click on "Vote for this issue" and add yourself as a watcher to be kept informed about the state of the features moving forward.