@Ash Young Thank you for your responses and helpful information. I have questions remaining, if I may.
1. When does this new functionality become available? I am not finding a place where I can assign such roles. I am using Managed Accounts and not Atlassian Access, for example, if that makes any difference.
3. The Collaborator role seems ideal for us. We are planning to create a JSM project for internal ticketing items such as requesting IT support, asking for a vacation request, and so on. Thus, we need our employees, many of whom also happen to be Developers on other Jira projects, as Customers to the JSM project. But, of course, we don't want to incur an Agent license for every employee. We also have employees who, present, have nothing to do with our Atlassian products. We also will need a few people to be Collaborators to help guide the JSM Agents in their processing of these internal requests.
4. Does the Collaborator role incur an Agent license cost? Or, any additional cost beyond their existing license cost as a typical Jira project Developer?
5. I am assuming that once our internal JSM project is created, we would assign specific people to be Agents (and incur the Agent license fee) and other individuals to be Collaborators (additional fee? no additional fee?), and finally, the vast majority of our employees as Customers to that specific internal JSM project - regardless of their role in other Jira projects, if any. We would be adding our non-technical administrative personnel to Managed Accounts and have them hold the role of Customer on this one internal JSM project. They have no need to have access to any other project in our Atlassian instance beyond the internal JSM project.
Whilst it is great to see this work progressing I wonder if the impact upon the users of JSM widgets has also been considered for this change. Especially where one of the requirements for using a widget is to have an open portal. Could the internal customers be allowed to have access to the widget?
Also are you or any of your team going to be at Team 23 to talk further about these upcoming changes?
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
I hope we get notified when our Cloud JSM instance gets changed over. Otherwise we have to keep looking for that 'Customer' role to be added to our Atlassian Security settings.
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Why FORCE every person in an organisation to create an Atlassian account. I have a JSM instance that has 200 licensed users and an organisation of 2500 staff. Until recently any of those 2500 staff could submit a ticket to my open access portal WITHOUT signing up. Now you are forcing them to create an Atlassian account all because I've approved the Domain. Poor form Atlassian!! I've now had to disable approved domains and have to trawl the customer list every day to identify customers who've signed up that I may wish to add as users
Atlassian Accounts with the "None" role (No Product Access) won’t be able to raise support requests.
The purpose of this role type is to explicitly restrict the specific user from JSM. If a user configured with "None", this represents a Administrator’s specific decision that the they should not have access to any JSM features.
I'm interest to here what scenarios you've configured where the help centre is disable, but you continue to provide support via email?
I have noticed that whereas previously you could search for, edit or delete a JSM user via User Management, the Jira Service Management tab has now gone. In the project, under People, you can delete the user from the project, but you can't just delete the customer altogether. So renaming and deleting a customer are two options that appear to be missing from this change, or is there somewhere else that you've added this feature please?
Since you are interested in what scenarios there are configured where the help center is disabled, but support is provided by mail the following:
When we started implementing Jira Service Management a requirement from the business side was that customers could keep on emailing as they were used to. Consequently, we decided to use the addon "EmailThisIssue", we don't send status notifications to customers, and do not communicate the URL of the self-service portal to customers.
However, of course, from an IT service management point of view that's not the desired end state; we want to start implementing request forms for some of our internal customers for some common service requests like for instance granting rights and hardware in the onboarding process of a new employee. So, in this scenario, we want to enable the self-service portal for (some of) our internal customers and disable access for external customers.
If I'm understanding this right, this will lead to potentially a substantial increase in administration workload, since we now need to assign someone to periodically see all the new customers that signed up to provide them access, whereas before customers could sign up without needing an administrator to approve them.
Is there a way to automate this so that we blanket accept all new sign-ups as customers?
This change only applies to internal customers (i.e. your colleagues from other department), You can add your company domain to the Approved domain list and automatically assign the customer role to these colleagues when they sign up.
If your customers are external (i.e. your customers that use services provided by your company). They should not impacted by this change.
You can learn more from here about the best approach for managing your customers
HI Ash, I'm not concerned now about removing users, I can see how to do that. I am concerned about not being able to change the displayed name of the customer, instead of it just showing the email address. Previously, when you went into Manage Users, there was a separate Jira Service Management menu option, and if you selected that you could select the customer and update their displayed name. This functionality has been removed, so please can you advise how I can change the displayed name of a JSM customer as sometimes there is confusion. Thanks
What else do I need to do for my people with only the new customer product account for them to be able to access and create tickets in service desk portals? Should they be able to access all portals with just the customer product access or do I need to do something in my project as well? Add the new group jira-servicemanagement-customer under People in my project? and if so, which project role should they have? User or Service desk customers?
Or do we need to change anything in the global Customer access settings?
We use Jira Cloud
I first thought that all they needed was the new Customer product access and they should be able to access the service desk portals but that don't seem to work so I am guessing I need to do something else. :)
We consider that Two-factor Authentification important.
Portal-only accounts don't have access to setup 2FA . If I am wrong, please provide instructions on how/where can a portal client go to in order to setup 2FA on their account.
Alright, the new feature sounds good, but what will be the best practice for managing the accounts having the "Customer" role in organizations, which is crucial? First, invite a customer as an internal account and then add the internal account to an organization - sounds like double work.
If so, why do the "portal-only" accounts still exist, and does the "Add Customer" button within the Organization page?
Shouldn't these "portal-only" and "internal" accounts be merged into a single management entity, along with the "organizations" already?
115 comments