Hi a1217920d496.

I concur with aa16d95cf9d4's suggestions to have Atlassian groups be able to be synced with Organizations as well as taking user attributes from an IDP and making them available as Customer attributes.

Our IDP is setup for auto-provisioning, which ensures that all users can raise requests in our help center.

The biggest pain points we have regarding Organizations are:

1. Certain areas of the organization want to be able to see all requests raised by members of their organizational unit and there is no way to effectively manage organizations at scale (10K+ users)
2. For major issues (e.g. our ERP is down or we've lost network connectivity at a site) we don't appear to have a way to make a specific issue visible to ALL portal customers without manually adding them to a single organization

Regarding Customer attributes, we currently use a JSM assets-based approach where we have had to:

• Create objects for every user and populate various attributes (title, phone number, department, supervisor, country / region, etc.)
• Use automation after a ticket is submitted to match the Reporter to the Customer object
• Use another automation rule to then perform AQL lookups on the Customer object and add all the attributes (which enables us to easily contact the user, filter by user / region / etc.)

I'd be happy to jump on a call to discuss our use cases further if you're interested.

Hi a1217920d496, for a couple of external support use-cases, it may be helpful to have a separate Identity Provider connected as the portal-only customer Active Directory. I have run into a scenario at multiple past companies where the customer directory is stored differently from the internal employees and the customers are from many different domains that the company has no control over (the "external helpseeker" scenario that you described). For those cases, we setup certain triggers to create the portal-only customer via API in advance of when we need to proactively contact the customer or we rely on inbound emails to create their account. It may have been helpful to truly connect a directory to create these portal-only users and potentially have all active customers setup with portal-only users in the appropriate Jira instances. The new SSO layer for external customers is tremendous and helps fill the biggest gap of tying the customer login to their single source of truth that they know in association with a company.

It still could be nice to have an AD setup that will create/deactivate/delete portal-only accounts based on their status as an active/inactive customer. There now is the possibility to have more than one Identity Provider associated with an Org, so maybe this is closer to being possible now (but I haven't tried it). I think the one issue is that these connections make internal users and the scenarios I am describing will never need Atlassian accounts and should always remain as portal-only.

Hi Ash,

Our "main usecase" for our Service Desk is "internal Users" and assigning Managed Atlassian Accounts via Atlassian Access to the "Customer" Role is what we do.

Whilst it was an initial hurdle to understand the concept, it has become second nature at this point.

Users becoming billable was a concern during our Migration last year, but was not an actual issue after getting to know everything with our Migraiton Partner and Atlassian.

It would feel "wrong" to have multiple AAD Syncs in different places for this usecase, so the current System works perfectly fine for us.

However, the integration with "Organizations" in JSD is "lackluster" - we would love to Sync AAD Groups (which are Synced to Atlassian Access) with "Organizations" as it is a core way for us to communicate Requests with different User Groups (for example during Outages - Statuspage would be overkill for us). Currently, a Third Party App Provider gives us this functionality.

Additionally, it would be awesome if Data Fields from AAD/Atlas could be displayed in the "Customer Widget" instead of having to manually fill them in for all employees - knowing at which Office a or Team a User is physically located helps our Helpdesk Team tremendously and speeds up their work significantly. This is currently not possible in an automated fashion, despite the Data being in AAD already.

I hope this feedback is valuable!

Hi all - Ash here, the Product Manager working on bring SCIM for Portal-only accounts to life.

I need some fresh perspectives from this group on how you would implement AD sync for your Portal-only accounts.

Please share here as a comment or via this email jps@earlyaccessprogram.atlassian.net

If you've provisioned your employees with Portal-only accounts in past - the follow is worth a read to reconsider if you've got the right config in place.

But before you comment! Here are some clarifying points to ensure our existing solutions that might meet your use case.

1. Am i billed for Atlassian access for users that only raise tickets on JSM?

It is possible to:

• Give users that only need to raise JSM ticket Atlassian accounts (Do not use other Atlassian products)
• Manage these Atlassian accounts with SCIM & SSO
• Not be charged for Atlassian Access.

Short answer - Yes, no extra Access costs (If they only raise JSM tickets)

Atlassian accounts now have a new JSM role called "Customer" - for more details see here. This role is specifically designed to for Atlassian account users that only raise tickets.

This is a non-billable role for JSM and for Atlassian Access

For a user to be billable - they need to meet all three of these criteria:

1. Are they a managed user? [Yes (/)]
2. Are they in a billable policy [Yes (/)]
3. Do they have product access or a role that is billable for Access (in any organization) [No (x)]

The JSM role is considered non-billable for JSM & Access - therefore this user does not add to your Access bill.

Note: the user will become billable for Access if they are assigned product access/role that is billable for Access - see here. 

2. Am i using the right account type for my users? (Portal-only accounts vs Atlassian accounts)

• Portal-only accounts are site specific and designed for "external helpseekers". This could be clients, customers, prospective clients that do not collaborate with you on Atlassian products.
• Atlassian accounts are global and are tied to the individual's email - they are designed for "internal helpseekers". This could be permanent employees, contractors, casuals that collaborate on Atlassian products.

We strongly recommend you use Atlassian account for your "internal helpseekers". This option simplifies account management for admins and eliminates the need to manage different account types and permissions.

There is no billing difference (If the users only uses JSM to raise tickets and doesnt have product access to other Atlassian products), and they are able to access SCIM & SSO today as part of your Access subscription.

For a more detailed breakdown of "external" vs "internal" see here

Thanks in advance,

Ash

Hey all,

We've highlighted this feature on our public roadmap - you can see more here

If you're interested in the feature, then we're interested in speaking to you . You can send an email to reach the team working on this feature: jps@earlyaccessprogram.atlassian.net

Thanks,

Ash

This is a key feature for security compliances to onboard the customer to the portal via azure active directory sync. Please prioritize this. 

Hey 3cca267ebf02, 

The basic principle here is that users without product access are not billable in Access.

The easiest way to manage this in via your default product access. Make it so users have no default access, then use groups to grant access (e.g. it-department group might be granted JSM Agent licenses).

That way every user in your directory has an account provisioned and can access the Help Centre, but only those who have been granted licenses can access products and ultimately are billed. 

Read more here https://confluence.atlassian.com/cloudkb/configure-atlassian-access-saml-single-sign-on-and-user-provisioning-for-customer-accounts-in-jira-service-management-1038778740.html

Cheers, 

Ben.

We are interested in using Access to do this sync, but I can't find a way to do so without 4x our annual subscription cost.
 
I know there is a non-billable access policy in Access. Is there a way to automatically add users to the non-billable security policy via a group or other method?  Manually moving 500+ users isn't something I wish to do.

Hi 7ad1551c39c0, I think we already chatted about this a while back, but the big problem is that there are not even any workarounds to properly integrate your customers when you do not control their domains.  We have no way for non site-admin agents to edit the customer display name nor align their passwords (but we already know all of those details from our source of truth like Scott is mentioning).  We need a way to tie in a non-managed domain directory so that it is synced to the source(s) of truth and we need a way to update portal-only customers via API and we need a way for the Service Desk Team agents to edit customer display names in the customer section of the projects.  We at least need the door to be open to build those first two pieces ourselves via API.  Here are some related suggestions:

JSDCLOUD-4551 Agents should be able to set username & full name of customers - Create and track feature requests for Atlassian products.
JSDCLOUD-5695 Set customer account's password through REST API - Create and track feature requests for Atlassian products.
JSDCLOUD-9396 Create Customer API should require only Service desk administrator permission and not Jira Administrator Global permission - Create and track feature requests for Atlassian products.

jared.bates1214341460 - You can add a group to the service desk via the Project Admin > People menu. Add the group as a Service Desk Customer, then all future members of the group will have access.

6f67b89f77fe - I haven't tested that personally, but if your guests are in an AD group that synchronises with Atlassian Access, then it should work fine. The only thing to note here is they will be full users with Atlassian Accounts, and not Customers Accounts. Assuming you have your default permissions set right this will be ok, but it requires careful consideration.

scott.d.fedorov - I was hoping people, like you did would share via comment on the ticket (thanks for doing so). Both of the things you mention here are things we are looking to focus on. It would be good to hear more about your setup, if you are open, please grab a time in my calendar to discuss further.