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 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.

@Benjamin Paton 

You solicited for feedback on use cases but didn't leave contact information?

Specifically you asked why we aren't using Access. In our use case, I work for a very large company. We are unable to claim ownership of our email domain because that would require claiming for the entire company, which is not needed. 

Additionally, the vast majority of our "customers" are not a part of our organization, but are external, so we couldn't claim them anyway. We provide web portals for our external customer to access our systems, so they already have logins with us, but now have to have separate logins for the service desk. The use case here is simple, we'd like our users to have just one login, the same they use for our web portals, to be used for the service desk also.

@Benjamin Paton does this also work with guest users in our Azure AD? We are looking for a solution that allows external users to login using a single set of credentials for all our cloud services.

We have our users provisioned in Access. The problem for us is manually adding each user to the service desk customer list. Say we hire a new employee, we want them to be provisioned automatically based off of an AD group, rather than adding yet another step to our help desk's already complex user setup workflow.

Hey 788921a36020, if your customers are members of your organisation, you can synchronise them with Atlassian Access for free. Access only charges you for users who have paid licenses. Users do not need licenses to be customers of your help portal. 

Let me know if this helps.

Just to add to this as far as our use case goes: We're a relatively small organization trying to leverage Jira Service Desk (Cloud) as out IT help desk. It would be helpful to be able to synchronize users from our local or synced Azure AD so that we don't have to deal with people getting flustered about emails asking them to sign up for things. Atlassian Access isn't an option for us due to cost primarily.

Thanks greg.draper310998593, it would be good to hear more about your use case. Please feel free to grab a time in my calendar that works.

Thanks for the transparency, Ben.  Just to answer your question, Atlassian Access only works if you own the domain.  Most people's customers are from domains that they do not own (and sometimes domains that are owned but that use a different identity provider).  Along with domains that we do own, there is no way to sync in multiple identity providers and there is no way to interact with the Jira Service Management Customer API to update portal-only customers, so you have no sustainable way to keep display names and passwords of your customers from drifting.  So we do use Atlassian Access for the users that we can, but that isn't enough.

I brought this up before Atlassian Access launched and one of your colleagues mentioned that looking at Service Desk customers was an oversight (I can sync up with you in more detail about this).  Thanks!

Hey all,

We are strategically looking at this issue, and the broader Customer Management story. We are working on the associated dependencies, and are planning on outcomes beginning after June 2021. I will update again as we pass through the mid-year planning cycle. 

I am interested in learning more about organisations who are looking to synchronise customers via AD, and why they are not using Atlassian Access.

If this is you, let me know. 

Cheers, 

Ben.

any update on this?

This would be incredibly helpful and save us a lot of time configuring users, plus our users would benefit by not having to login to the portal each time they want to review a request. Please add!

I 100% agree this should be basic functionally. Without this ability we can't track user demographic's as we rely on the user to populate and keep the correct data. I shouldn't have to purchase Atlassian Access to do this simple task. 

Thank you so much for clarifying this @Greg - GoDaddy

We own our domain and all users we want to have access are withing the organisation so then it should work just fine. Happy  

Hi Reza (and others),

Just to clarify if it helps, Atlassian does support Active Directory integration with Jira Service Desk Cloud (and Jira Cloud) and they support multiple identity providers (Okta, OneLogin, Azure, Google) along with a custom SCIM integration via API if you want:  https://confluence.atlassian.com/cloud/user-provisioning-959305316.html

Couple caveats:

1. You can only sync a single identity provider into each Org that you setup and you need to own the domain(s)... so you can have multiple domains that you verify going to the same Org/products as long as they are using the same identity provider.
2. You don't have a way to sync in your external portal-only customers (people that all have different domains)... that is the big gap for my use-cases where I know who all of my customers are, but I have no way to sync them since I do not have authority over their domains

It works great for internal people (even if you just want to have your internal people be customers of your service desk).

+1

Not having support for AD for cloud version is a very big miss. I'm not sure we can go ahead with this purchase without it. 

We dont have a huge organisation but adding 250+ users who already have multiple logins for a crucial system is a no no. 

I can only agree with Jonathan too... The client was surprised to find that something so basic wasn't supported

Can only agree with Jonathan, this is basic functionality for such a tool in 2020.

I wish someone at Atlassian would investigate this issue, this is killing uptake of my helpdesk and was raised 6 years ago. This isnt even a narrow user case, I suspect this is the situation most people would find themselves in... 

I hate to be that guy but its 2020 and nuts that Jira does not have this functionality. As everyone is moving away from endless passwords towards SSA, Jira is not even trying. 

Our company also uses ServiceNow, but I've been lobbying for Jira Service Desk for my group due to the much better UX and ease of use.  However, if every internal customer (~16,000 possible people submitting tickets to a 20 person team) has to create and manage a separate Atlassian account, it will most likely disqualify Jira.

We recently moved to cloud only to discover that we can no longer provide SSO from our other apps to ServiceDesk for our clients. This is very important to us. We, as I would hope most companies would, place a great deal of value on providing our customers with a seamless experience. Requiring our customers to log in a second time to get to our support pages reflects badly on us and in turn on Atlassian. This one may not get as many votes as some other issues but the high visibility of this issue should give it a higher priority. 

Agree with the above, the connector is nice, but a) limited to 5000 which can be an issue if you want to import all Users as customers and b) it only sync's name and email, no option to get additional fields, although some of the documents state different...

Hi, 

the issue with the mentioned user provisioning for our company is the limitation to 5000 users, which is ok if you define users as people "working" in the system. That's why customer integration of more than 5000 is needed to get "end-users" raising issues into the system. I would agree that you could do both, if the limitation of the user provisioning could be overcome.  

Hi,

they recently enabled the user provisioning feature for Azure AD, you should take a look at it here: https://confluence.atlassian.com/cloud/user-provisioning-959305316.html

I've just set it up and it works great.

This is also blocking our migration to Jira in the cloud.

We actually need this.

This is a crucial feature and I can't imagine you're gaining market share without AD integration. Just looking to switch to Jira Service Desk because of the great UI, but I can't in good conscience recommend a toolset that comes with an admin headache. I'll keep an eye out to see if this gets delivered, but in the interim I'm going to stick with our existing system.

I agree that this feature is critical and has been overlooked.  Let me explain the use-case in more detail since a lot of people are listing a work-around that does not apply.

To summarize, for Jira Service Desk Cloud, if you want to provision your internal employees to be JSD agents and Jira Software users through your active directory and then also sync your external customers who have many different email domains through a different directory, you are stuck right now.  Because you cannot sync their login passwords and cannot edit their name to keep it in sync on changes in your primary system.  You instead force the customer to maintain two passwords and their name data drifts.

The UI allows you to change these things, but you cannot touch them through the API.

Atlassian Access works on a domain basis (you authorize entire domains).  We have been running with G Suite for a long time for our internal users and more recently added Okta through Atlassian Access for additional internal users (we have a lot of internal users too).  These work great for internal, but our customers are on every domain that you can think of and are not stored in the same directory as internal users, so we have no way to keep them updated.  We do add them via API, but have no way to set their password or update their name on a change.  I should also add that we have over 40,000 JSD customers and so manual updates are not an option.

We really like Jira and Jira Service Desk, but this is a big gap that would greatly expand Atlassian's customer base if they provide a way to sync a custom directory straight into the "Portal only customers" and each service desk project of your choice.  Then it could activate, update, and deactivate those customers through a separate mechanism.  Sorry to ramble... hopefully this helps.

Hey any update on this? we also would like to move to JSD in the cloud but need to have customers automatically created based on Azure AD

Hello everyone!

If we can connect Atlassian Access with Azure AD, do we need something else to automatically create a JSD customer with the same credentials as AD?

We are trying to implement JSD as our ITSM tool (the request fulfillment part) but we would our customers to automatically have an account with the same credentials as AD.

Thanks!

Gabriel

Tried Atlassian Access, this just creates a bigger mess and doesn't integrate properly with JSD.

Is there a chance that Atlassian Access solves this issue?

This integration with AD and user provisioning is what is preventing us from selecting Service Desk as out ITSM solution.

Please make this happen!

I agree with the other comments, it should be way easier to get internal (Active Directory/Azure Active Directory) users up and running as Service Desk customers. At least there should be some kind of automatic csv import or the self-signup process should work with SAML for Service Desk customers the same way it does for normal Jira users.

This SSO integration piece for Jira Service Desk customers is a big mess and a dealbreaker.
I should be able to import a bunch of AD accounts and have it pull details such as name for assigning ticket requesters.

This needs a a fix.

We are just now implementing Jira Service Desk in the Cloud. For several of our SaaS applications in the cloud we have Azure SSO with automatic account management working. 

So if I understand all this, and I probably don't... but fortunately I work with a couple of knowledgeable SSO/Identity managers, we should be able to get SSO working. It's automatically provisioning Jira Service Desk Customer accounts for our employees that will be the issue? 

Until there is an integration that can automatically create and delete accounts, I want to make sure I understand our options. As a university was have over 15,000 students, faculty, and staff. Every year we add thousands and delete thousands. Only a fraction of these people will ever use our Service Desk. 

I am kind of wondering: Why should we provision their Service Desk customer portal accounts ahead of time? We can make our Confluence articles public and just let them self-create portal accounts with their university email addresses as needed, right? As long as we have SSO enabled in some fashion, will they be able to sign in using their AD password? Their email addresses are the same as their UPN that they use to sign into Microsoft Office 365.

Sorry, but the workarounds are really not a good way, especially as this seems not to work with Jira Cloud?

Especially as you can select "serving internal customers" in the project creation wizzard it seems that JSD is a lot focussed on external customers so far...

Any status on this? This is a crucial part for customers integration in Service Desk portal. THis may be a show stopper for being a management overhead task of adding and removing customers (creating requests on behalf of customers) in dynamic organizations where contractors start and leave companies on a daily basis.

Adding this here as I've found these steps to be correct in getting Customers to use SSO in the JIRA SD Cloud.

1. Add the customer to the project under Projects>(Project)>Customers
2. Go to Administration>System>Project Roles
3. Next to Service Desk Customers Click on Manage Default Members
4. Click Edit under Default Users
5. Add the Customers to this role and click Add
6. Go to User Management > Portal Only Customers
7. Click on the Customer’s email address
8. Click Convert to Atlassian Account and Convert
9. If done correctly the Customer will convert to a User and the Service Desk Access box will not be checked and will not user a license. If it is, simply uncheck the box and the effect will be the same. 

This is a SUPREMELY convoluted process for something that should be so incredibly simple. For us, its may take an hour but I can get all of my customers added this way and be done with it. This may NOT be an option for others who have more than 200 customers to add.

I'm failing to understand why this hasn't been resolved after 2.5 years (first post i saw on this was OCT 2014). You already have the SAML/SSO functionality; all you need to do is give use the option of set whether the default user group has access to the Jira Service desk. Alternatively, give us the OPTION to automatically assign a license to newly created users.

Have someone integrate the JIRA Service Desk user base with an external application?

I don't think that above work arounds are any good. This problem is related to the cloud version of the product and as such, Vivek's workaround does not unfortunately work. There is no "User Directory" option within the user management screen.

Guys, there are workarounds for this, as explained in comments above, just use them. I believe Atlassian are not in a big hurry to do this, as it is complicated and there are working solutions to overcome it.

We are also in transition from other tools to JIRA but having service desk without AD authentication is a big problem. Can there be an anwser from Atlassian representative?

We are considering JIRA Service Desk on Demand but not having AD authentication is a deal breaker for us as our current solution has that capability so moving to JIRA would be a step backwards and require more work on our end. I would like a definite answer from Atlassian on if this is in the road map or not?

There are multiple stories for AD integration and I'm not sure why they are all not linked...
This is a huge priority, but it doesn't seem as though Atlassian cares about this as much as other features... If they only understood that getting this integration would gain them a LOT more customers\money maybe they would focus on it...