@Austin Songer - two accounts is a bit of a red-flag to the anti-spam bots, and I think they hit you with it. I've pulled one of your posts out of spam because it's simply not.
I also wanted to reply to your first post. I'm not saying I've got a better name for customer accounts, I really don't, but I do think we need a way to have different names for the two types of customer, Agents and developers. We're already charged for "internal" customers (as they're developers or agents already), I would not expect Atlassian to impose another charge band on them.
We currently have all of our staff in the "Service Desk Team" role so that they can navigate to our service desk project: https://[instance].atlassian.net/projects/[service-desk-project-key] in order to add internal comments. Most of our staff don't have the Service Management product toggled on, only agents are licensed that way.
With this change, will our unlicensed staff members still be able to view that project and view tickets via https://[instance].atlassian.net/browse/[issue-key] rather than being forced to view tickets via the customer portal https://[instance].atlassian.net/servicedesk/customer/portal/[portal-id]/[issue-key]? That's pretty important for them being able to add internal comments and to see additional fields that are hidden in the customer portal.
As an aside, we currently also share some filters with an external consultant who has a Jira account in our instance but has no permissions to the service desk other than via the customer portal. That filter's results show links to service desk issues but the URL is not changed to the /servicedesk/customer/portal... URL for them based on their permissions but stays as /browse/[issue-key] so the link is useless for them. Can that be fixed (checking permissions and outputting the correct URL based on the viewers permissions)?
What about segregated customer permissions for each JSM portal? I don't want portal users to browser other JSM portals.
I use an internal JSM portal for staff and an external JSM in another project for external users to raise requests. I don't want these random external users being able to view the internal JSM portal. If i butcher the project permissions for the external JSM, it disables email requests from vendor/supplier/any 3rd party unknown accounts for my internal JSM project.
We revoke the User when they leave our company so we stay with in the 10 licenses we have, (small part of our company using this instance of JSM). I discovered just last week that when I revoked my old manager from JSM, last October, that they were still in a Group. - it still doesn't consume a license, but I would have thought that they would have been removed from everything to do with our JSM instance.
10 x users who consume a license - it bounces around 8-10 and 45-ish Customers who are in groups
Can you please confirm that they will remain in the current groups that restricts what they can see with these changes.
What do I need to do? Can I do nothing? Do you have a step by step guide of what I need to do with screen shots. ( I find JSM admin very difficult to find where things are located)
I need to advise my management of these changes and what 'Dollar Cost' it will be to us as company.
I currently have a ticket in for Tagging 'teams' in a comment with in JSM for example tagging a team called @Cup of Coffee , where I can tag unknown random teams made up by others not in my instance and who I haven't added to my Organization. I've been told that these randoms can not see my data as it is now (I can't prove that they can't or can see my data) Atlassian advised that I'd need to grant permissions to the project etc etc for them to see my data. Has this been tested with these changes?
I've spent some time today updating the original blog post with some additional detail and an FAQ to address some of your concerns and questions. Apologies if this blog had set off any jitters.
In the spirit of transparency - we release features with customers like you in mind. If you're not convinced or onboard, we've clearly got some talking points to work though.
If you still have questions about your specific scenario or are open to having a chat about the changes. I'm more than happy for you to reach out via email and we can discuss further or jump on a call: ayoung3@atlassian.com
- Internal staff who raise tickets for customers under the "customers role" (non billable)
-Agents who work on these tickets (billable)
So how does the update change this in anyway?
We also have internal colleagues who raise tickets on behalf of customers they do not work on the ticket in anyway so have "customer" access but then that means they raise a ticket under our company rather the client is there a way to automate so that if someone adds the link to the site to the clients company in the ticket it automates to choose that clients organisation and epic?
We do not want to change the internal staffs access as they are equivalent to customers and do not feel the need to pay for them to have a service they will never use.
You can continue to configure default product access settings for groups.
Where you would have historically configured “None” - you would in future configure “Customer”.
This configuration will be adjusted in the background for existing JSM sites as part of the migration. Our aim is for these changes to be behind the scenes and non-disruptive for Admins.
@Humberto Gomes I can make an internal user with JSM license an agent in one project and a customer in another by adding them to Agents/Customers roles respectively.
I agree with @Shazna Begum (Shaz) if you don't want staff to have access to the application then don't add them to JSM.
We have a lot of staff who are not in JSM and will not be added.
This is what I do now, I audit the Customer's (non licensed people) if they have never been active or if its been a while since they logged in, I remove them. It makes my future job of auditing easier. If they ask for access again it is reconsidered.
The same applies to Users (people who expend a JSM License). I audit them and remove them if they are not using the application.
This change article refers to Internal Customers and External Customers - imo this makes it more confusing than it needs to be to understand what is being changed.
JSM has Users and Customers
The confusing thing for me is the terminology being used in this article where the application and new screen shot still refer to Customer and User, and None
For me we will not have None if they are considered None then they will not be in JSM.
Looking at the table the yellow highlight are the same.
WRT We are taking another step forward in helping you manage your customers in JSM.
Is this a step to being able to increase the number of licenses required in the future for internal Staff?
This change simply introduces granular control for Atlassian Accounts. Instead of having no option to restrict JSM Help Center access - we're giving Administrators more control over access.
What happens if a user is assigned "None" today
If a user has an Atlassian Account and has the "None" role, or you might refer to this as "removing product access". They would still have access to the JSM Help Center.
In this scenario the Administrator has tried to remove the Atlassian Account's access to JSM, but the user is still able to view the Help Center. This behaviour does not match the Administrator's intentions.
What happens if a user is assigned "None" in the future
If a user has an Atlassian Account and has the "None" role assigned. They will no longer be able to access the JSM Help Center. This behaviour matches the Administrator's intentions.
If the Administrator intended for the user to have access to a JSM Help Center. They should use the "Customer" role to specify which Sites/Help Centers the user should have access to.
How this benefits Administrators
Granular control over which Atlassian Accounts have access to individual Help Centers
Increased security over sensitive Help Centers
Clearer Product access settings that best represent an Administrator's intentions.
As I ventured through the reactions here, you might to stress out from the start, that the main use is that you now can decide which of your Atlassian Access users see which of your JSM Projects in the main portal to guide them better, Because as I see it, that's simply what there is. No more, but no less either.
Hi! Where can I view Atlassian account users designated as "None" in my organization's system, or where can I if this is something that will rollout in the update?
That would be helpful to ensure that none of our users are unable to access our Help Center.
We migrate all our Portal-only customer accounts to Altassian accounts because portal-only accounts do not offer the Two-Step Authentification feature, based on our testings.
I'm hoping the Atlassian Team can comment on this, and confirm our findings.
Any users that have the JSM "User (Agent)" role will incur a cost - these users have access to JSM's issue view and have access to handle requests on the JSM platform.
As of today, we haven't rolled out the "Customer" role just yet.
Right now, if you only need an Atlassian Account user to access the Help Center. You can simply remove their JSM product access (assigning them "None"). This is non-billable so you won't be charged to only access the Help Center.
After we roll out the "Customer" role - this use will be migrated from "None" to "Customer" behind the scenes. The new "Customer" role is also non-billable, so rest assured there is no additional charge here.
Provided you have administrator access you'll be able to change your user's product access.
As mentioned in the blog post, these changes aren't live yet. We have a migration plan where current users that have "None" will be migrated to "Customer. This will ensure that none of your end users lose access to the Help Centre.
115 comments