Choosing the right approach to Customer Management in Jira Service Management

[#1]

Latest information

We have recently publish a blog providing information for the upcoming SSO for Portal-only Customer Accounts feature. Please have a look and leave a comment with your thoughts

Upcoming SSO capabilities for external customers in Jira Service Management

Customers are the heart of any company. In JSM, your customers experience is critical to the success of your service desk. This makes an effective Customer Management Strategy paramount for every admin. Each company is different, and have different customers. As such, it is important that you select the right Customer Management Strategy to meet your needs.

At the core of your strategy is understanding who your customer will be

• Internal Customers: Typically employees of your company. Where a service is openly provided by one or more teams to the members of your company.

• External Customers: Users who are outside of your company. Often a subset of the general public. Where your company provides a service to external individuals/groups maybe known as clients or customers.

• Hybrid Customers: A combination of both internal and external. Where some teams service members of your company, while others service those outside your company.

Different customer types require different approaches to sign-up, access, and permissions. It is also valuable to understand how Atlassian Product Users are managed and provisioned. Atlassian Access although most commonly know for managing licensed users, is a value utility for Internal Customer Management, and lets you extend SSO capabilities to those users.

Throughout this article we will explore the best practise for each strategy. We will identify what is possible today, and where new features are coming that will improve the experience.

Account types

Atlassian Accounts

Portal-only Customer Accounts

✅  Same account can be used for collaboration across multiple Atlassian product. ✅  Users can sign-in using business accounts (e.g. Google, Microsoft, Slack, Apple). ✅  Able to be added to groups for managing permissions. ✅  Password policy can be applied. ✅  Single login for all Atlassian products and sites. ✅  Advanced user management and metrics (with Access) ❌  Limited to the maximum organisation user base size (currently 75,000*).

✅  White-labelled sign-in experience. ✅  Unlimited. ✅  Unique to each JSM site. ❌  Cannot be reused across multiple sites. ❌  Unable to be added to groups. Can only be manually added to Organisations. ❌  Email and password is the only method of authentication.

_{* If this presents a problem for your organisation, please contact your Account Manager to discuss alternatives.}

---

Internal Strategy

This strategy is for organisations where all customers are employees, contractors, or stakeholders of a central company. External customers will never be invited into any aspect of the help centre. It is common for customers too also be users of JSM or other Atlassian products.

Common examples: ITSM Teams, HR Teams, Legal Teams, Finance Teams

Front of mind: Frictionless access, Security, Sign Sign-On, Cost effective

For this strategy we recommend using Internal Customer Accounts (also referred to as Atlassian Accounts). Using Atlassian Access is not required, but will provide the best experience.

Customers configured in this way with no product licenses will not incur any cost through any product (including Atlassian Access).

Step	Internal Customers (with Access)	Internal Customers (without Access)
Provisioning Customers	With your IDP connected you can choose which groups will be automatically synchronised as Internal Customer Accounts (also referred to as Atlassian Accounts).	Using a domain based allow list for Jira/Confluence product access you can automatically approve sign-up for Internal Customers. New feature Domain based sign-up for JSM Internal Customers.
Securing your help centre	Portal sign-up should be disabled.	Portal sign-up needs to be enabled. We recommend not allowing anonymous portal access. New feature Disable the creation of External Customers to improve security.
Controlling product access	Users synchronised via Atlassian Access will be given your default product access. Consider which product licenses are granted by default to avoid unwanted cost. It is recommended to provide no product access by default, then to utilise groups for granting specific product access.	Internal Customers created via the Help Centre will be given default product access. Consider which product licenses are granted by default to avoid unwanted cost. New feature Explicitly granted Internal Customer access to users (also applies to Atlassian Access).
Managing permissions	Service desks should be accessible to Anyone with an account on the site, except those service desks that need to be private. Soon Managing service desk access with groups and teams.	Service desks should be accessible to Anyone with an account on the site, except those service desks that need to be private.

External Strategy

This strategy is for organisations where all customers are external to the central company. Customers can be could be clients, end users, prospective clients. There are no internal business company interactions. It is common for the help centre to be publicly accessible.

Common examples: Customer Support Teams, Sales Teams

Front of mind: Seamless access, Flexibility, Brand, Email enabled

For this strategy we recommend using External Customer Accounts (also referred to as Portal-only Customer Accounts). Atlassian Access currently doesn't manage External Customer Accounts, but can be used to provision and manage your Agents. External Customer Accounts are always free and unlimited.

Step	External Customers
Provisioning Customers	A combination of self sign-up and Agent account creation is recommended. New feature SAML/SSO options for External Customer Accounts.
Securing your help centre	The recommended setting for most External Service Desks is Allow customers to create accounts. Depending on your customer base there are varying degrees of restriction which can be applied, from allowing access without requiring login to allowing access only by users with a pre-created account. New feature Domain based allow list for External Customer Accounts.
Controlling product access	External Customers Accounts can never be granted product access. They can only access your Help Center.
Managing permissions	Typically External Service Desks will be accessible to Anyone on the web. Where restriction is required, we recommend using Organisations for group customers and using those Organisations to grant access. Soon Automatically adding customer to organisations based on email domain.

Hybrid Strategy

This strategy is for organisations where both Internal and External Customers exist together. Customers will often live in two independent directories. It is common for Internal Service Desks to react to requests raised in External Service Desks.

Common examples: Admissions Teams, Recruitment Teams, Product Teams

Front of mind: Security, Delineation

For this strategy you must use both Internal and External Customer Accounts. Atlassian Access is not required, but will drastically simplify your management of Internal Customers Accounts. Strict permissions and tight group/organisation membership are critical to success.

Step	Internal Customers	External Customers
Provisioning Customers	Atlassian Access is the recommended approach for provisioning Internal Customers, but it is possible for Administrators to manually provision these customers, or utilising Domain based sign-up via other Atlassian products. The Internal Customer Accounts can be synchronised from a connected IDP based on group.	External Customer do not utilise Atlassian Access and should rely on a combination of self sign-up and Agent account creation.
Securing your help centre	For most hybrid Service Desks it will be necessary to Allow customers to create accounts. Pre-provisioned Internal Customer Accounts will avoid sign-up conflicts. New feature Domain based sign-up for JSM Internal Customers.	External Customers need to be able to sign-up or email into the help centre. The only exception here is if External Customers will be manually provisioned by Agents. New feature Domain based allow list for External Customer Accounts. Soon Automatically adding customer to organisations based on email domain.
Controlling product access	Users synchronised via Atlassian Access will be given your default product access. Consider which product licenses are granted by default to avoid unwanted cost. It is recommended to provide no product access by default, then to utilise groups for granting specific product access.	External Customers Accounts can never be granted product access. They can only access your Help Center.
Managing permissions	Service Desks that are intended for Internal Customers should be restricted to Customers added by agents and admins. Using groups is the most effective method for managing these permission, and can be done via the Project Admin > People menu in Classic projects.	To ensure new External Customers can open requests, at least one Service Desk will need to be accessible to Anyone on the web. The exception here is when all External Customers are manually provisioned and individual permissions are set. Service Desks can be allowed to a subset of External Customers based on manual Organisation memberships (this is good for differentiating service levels, paid customers, and/or customer groups). Soon Automatically adding customer to organisations based on email domain.

Multiple Customer Account Conflict

Internal Customers visiting the help centre for the first time will incorrectly generate an External Customer account if an account has not previously been provisioned for them.

If in future they create an Internal Customer account they will no longer be able to access the original External Customer account.

---

Vision for Customer Management

Our goal is to provide a comprehensive solution for managing customers in all business types.

This means…

• Creating a secure and seamless sign-in experience for internal service organisations.

• Avoiding the burden of double sign-in for external service organisations whose customers already have an identity

• Allowing the synchronisation of multiple user directories, and being able to effectively differentiate between internal and external customers

In the above best practise we have highlighted some gaps we have committed to address. Below we will provide more details about these features and a loose timeline for their completion. Our intention is to drive a broader conversation on these topics in a Community Group.

Domain based sign-up for Internal Customers

Released - March 2022 - Learn more

As highlighted in the best practise, Internal Customers are best served with Atlassian Accounts. It is difficult for organisations without Atlassian Access to enforce this approach.

This feature will provide the ability to create Atlassian Accounts via self sign-up for customers based on their email domain. This is similar, and utilises the same mechanism that Jira Software and Confluence do today.

Once enabled, domains added to Domain Enabled Sign-up for your Site/Organisation will automatically generate Internal Customer Accounts (also referred to as Atlassian Accounts) for users with a matched email domain. 

Domain based allow list for External Customers

Released - May 2022 - Learn more

To compliment businesses that work with a specific groups and/or companies, we are providing a way to restrict self sign-up for External Customer Accounts (also referred to as Portal-only Customer Accounts) to a specified list of email domains.

This helps in the scenario where let’s say your organisation only provide support to paid customers. Your customers are typically an organisation (e.g. we have a contract with acme.org). In this scenario each customers will be an unknown individual in a known company. By restricting self sign-up to anyone at acme.org you protect your help centre, while remaining flexible for your customers.

Disable the creation of External Customers to improve security

Released - May 2022 - Learn more

When using Jira Service Management purely for servicing Internal Customers, the ability for Project Admin and Agents to create External Customer accounts for users outside of the organisation can pose a security concern. This feature allows organisations to disable the creation of External Customer Accounts (also referred to as Portal-only Customer Accounts) when they are not required.

Explicitly granted Internal Customer access to users.

Released - March 2023 - Learn more

Today any users added to your Atlassian Organisations user base is an Internal Customer in each of your JSM Site automatically. For large organisations this provides limited control.

A user role dedicated to granting help centre access for Internal Customers will allow Administrators to choose who should have no, customer, or agent access to each JSM site.

Automatically adding customer to organisations based on email domain

Soon - June 2023 - https://jira.atlassian.com/browse/JSDCLOUD-4519

Organisations (not to be confused with your Atlassian Organisation) is the grouping method for External Customers. Organisations can be used for permissions and sharing for External Customer Accounts (also referred to as Portal-only Customer Accounts). Manually adding customers to Organisations is the only method available today.

This feature will allow Admins/Agents to define email domains which will be automatically sorted into Organisation. That is, when a customer signs up, if their email domain is matched by an Organisation, they will automatically be added to the Organisation.

This will make it easier for controlling access to individual service desks.

Managing service desk permissions/sharing with groups and teams

Soon - December 2023 - https://jira.atlassian.com/browse/JSDCLOUD-4867

In Classic project groups can be used to grant Internal Customer access to Service Desks via the Project admin > People page. This is not possible in Next-gen projects. Our goal is to bring this ability to the Customers page and make it available for all project types.

Beyond this, we want to make it possible to share ticket between customer in a group, the way that is possible with organisations today.

This includes extending these capability to include Teams.

SAML/SSO options for External Customer Accounts

Released - August 2023 - Learn more

Currently SAML/SSO via Atlassian Access is only available for Internal Customers Accounts (also referred to as Atlassian Accounts). This feature seeks to extend this capability to External Customer Accounts (also referred to as Portal-only Customer Accounts).

The goal here is to allow Identity Provider (IDP) configurations in Atlassian Access the ability to delegate groups to External Customer Accounts, then associated those groups of customers to Jira Service Management sites.

The ultimate here is to allow organisations to seamlessly authenticate their customers using their own user directories.

[d_kirsching]

Hi @Benjamin Paton 

I'm really interested by all these new features ! 

That could be resolved some problems with our Customer Management access.

Have a nice day.

Regards

[Antonio Valle _G2_]

Yes!

Very interesting functionalities. I'd like to add more capabilities of interacting across social media (I.E. instagram, twitter and FB integrations)

[Mikael Sandberg]

I'm interested!

[Jeremy Tang _Trimmy Choo_]

Exciting stuff and love the clear vision! @Benjamin Paton 

Definitely interested in the "Community Group dedicated to discussions focused on Customer Management"! We are using JSM for our external customers and are keen to see what else is in store to make their and our lives much better!!

[Johnson Ip]

The SAML / SSO options for External Customer Accounts might create some unintended consequences. We operate in something of a hybrid customer model where we have some service provider taking on some tickets for our customers. Since their organisation had configured Atlassian and had claimed they domain. We can no longer give access to "service_provider_helpdesk_at_their_domain.com" (their support email address) and just toss an issue across the fence. The SSO will redirect the support email to their organisation's ID provider for authentication and it will prevent them to sign in since the email is not defined as a user object. This had given us the headache of making them inform us of their staff movements so that we can set up their users individually. If the same mechanism is to be used for external customers, I would imagine that email address like "accounts_department_at_customer.com" will be blocked from login in and we will have to spend more time to obtain the context of these named individual external customers when they complain that their report is not working.

[Fiona Cunningham]

I'm interested!

[Ajay _view26_]

Sure !  Would be happy to be part of the early access group to provide feedback!

[Erin Collins-Valiantys]

It's great to see Atlassian making more distinction between external versus internal. The portal has some way to go, though, and authentication is just one branch of a a client's great customer management experience. 

I'm interested, and I want mooooooore.

[Jack Brickey]

Yes, yes, yes please invite me to this. This has been one of the more frustrating areas in JSM for me which might be obvious from my support tickets and Community posts on the subject. I am extremely hopeful for an overhaul in this area.

[Brian Watts]

Interested in this. We operate in a multi-tenanted fashion and ensuring the proper customers have the right licensing/rights is key

[Vinay Sharma]

@Benjamin Paton Good article!

[Greg D]

Thanks for putting this article together.  Great details!  We are interested in the early access group.  We have a hybrid model in multiple Jira sites and then internal for a few others.

As you know, our biggest challenge is being able to keep our portal-only customers in sync as service desk agents interact with them.

From our perspective servicing the external customers is the most powerful part of Jira Service Management, but we need the Service Desk Team role to be able to edit those portal-only display names from within a project and we want a way for the API to update those users too.  Right now, at scale, those customers are difficult to properly identify (we can service them like champs, but really could use more flexibility in managing the details about them).

After unlocking the display name editing for those customers for the non-admin level, it would be really beneficial to add the capability of adding a small note to their profile... those could show on their customer card on the internal side and could be edited if you click "View profile" to get to that People section (instead of ending up off the beaten track).  Then hopefully we get those profile cards to show on Request Participants and we will really be cooking with gas.

I would consider Service Desk Agents being able to edit external customer display names higher priority than every item on this list.

I forgot to add in an Irish blessing (been trying to pass these around today):

"A wish that every day for you will be happy from the start and may you always have good luck and a song within your heart."

[Stuart Capel - London]

This sounds awesome - I'd love to be part of a community group around it

[Evan Nixon]

I would love to have some input here!

Though I will give away the biggest request I have :

Portal Only Customers & The Curse of the Spooky View Profile Button

Look at this "View Profile" button. This view profile button looks like a nice button. Clean cut, respectful - hell, this button probably helps little old lady buttons cross the street. But it is not a nice button. This button leaves time on the microwave. This button kicks puppies. This button doesn't read the detailed responses to support tickets before replying. This button is the most evilest button that has ever existed. Even the button that primed the Death Star before it blow'd up Alderaan sees this button and is like "Bro, chill".

And along comes you, fresh and innocent as the dew on a brisk Spring morn', with hope in your eye and a spring in your step. Did you really think that clicking on the "View Profile" button would....what? Take you to view information about that user? See some information about their name, maybe a single line of contact info, or information about their tickets and organizations....a "Profile" if you will?

Nope! Guess again dumb-dumb, obviously that's the super secret bonus feature which lets you view a curated selection of various 404 pages that the designers at Atlassian have lovingly crafted!

No, seriously! It has literally done this over several design iterations! Golly-jee willikers, aint' that neat!

 



Myself and lots of other people have been asking for a fix for this since the year of our lord Two Thousand and Six Frickin' Teen so, hopefully a fix is coming "real soon". 

I know that adding a "literally anything other than broken page"...page would be so much work, so if there isn't room on the roadmap for implementing more than a button that alludes to this advanced feature, maybe you could spare a crack team of 12 Developers for a cycle or two to scope out an exploratory preliminary report on the feasability of having a conversation about a precursor to the organizational synergies that would be needed to......*checks notes*......change the text on the button?

I know that the several months of back breaking labour it would take to do this is an ask most bigboi in nature, but so as to be considerate of everyone's time I've taken the liberty of creating a new design mockup for you.  

🙃

[Greg D]

@Evan Nixon love the post.  This is a piece of what I was mentioning too.  I think that the customer profile should let you edit someone's display name and add a note about them to help all of the agents.

Right now you can only do that at the Jira Admin level, but moving it into the Customer section of a project makes so much more sense (it could be launched via the profile).

Who is test@testingtesterson.com?

A Jira Admin will never know that answer without help (and cannot maintain it manually at scale).  But a Service Desk Team Agent will.  And an API might.  Right now those two cannot do anything about it though.

In my opinion, a portal only customer's profile card should be editable by everyone as if you are that person.  Let us fill all of this out for the portal-only customers:

When you visit the People section and go to your own profile, you can change those other fields, but cannot edit the name directly there (so I am asking for a little more functionality since the most important thing is display name and then just a free-form note field would be good... but we could work with what already exists in the profile today as long as display name is editable).

Seems like it would be good to have a customer version of the profile that is very similar, but has an indicator that it is a portal-only account.  That could even let anyone with the Jira Service Management product access in the instance edit it (without adding more complexity of individual project role access to the profiles).

Then, everyone wins, because the card has better info for everyone when they are in Jira issues and the Customers section, the profile is no longer a dead link to an error page, and we can properly control our external service desk customers' information, no longer having incorrect display names nor anonymous email addresses in the site.

[Patricia Francezi]

@Benjamin Paton we have real interest in testing it, also put to our customers that already have needs related to all customer scenarios you exposed here. I think we may contribute a lot in the focused group, with suggestions, evaluations and also testing 

[Andreas Lärkfeldt]

Hi again @Benjamin Paton 

If I wasnt to much last time I’m More than interested joining the conversation.

kind regards

andreas

[Christian Olsson]

How about differentiating external customers access rights as in some external users could read and comment on tickets while others would be restricted to read only ?

[Emily Shaw - PeopleSpheres]

Definitely interested in this ! Our company is scaling and external support is at the centre of our operation. External customers' access is important and we've put a lot of work into making it work for our situation. Excited to see where this will be heading in the future ! 

[Pascal Kontschan]

Hi, i would love to take part in the community group and test early access feature.

My biggest wish currently is, having a nice way to manage customers (internal/external).
Maybe a second "user manager" called customer manager. Where organizations act like groups. Auto created by the accounts email domain. Or manually. And editable afterwards, Display Name, custom assignment rules, marking someone as Default Contact person, or other lables added to users (customers) on which rules can act in some way ...

Being able to assign a customer group / organization to a project or even on the request type level.
To be able to say, this customer has access to a more direct request type, with a more direct workflow. Because they have a better SLA with us. Because they Pay more, or whatever.
Differentiating the SLAs based on the requestors organization.

Thank You!

[Gianluca Folla]

err

[Danielle Naoman]

Definitely interested!

[Benjamin Paton]

Hello all, 

Sorry for the delay on my reply here. I have been working to get the group together and I have updated the article to contain a link for it - https://community.atlassian.com/t5/Customer-Management-for-Jira/gh-p/customer-management-jsm

We are kicking off with three discussion threads, but will be adding more soon.

Now for some direct responses

@Antonio Valle _G2_ - Interesting, do you mean sign-up/in via social or receiving requests via those channels?

@Johnson Ip - I agree the segmentation of user groups across multiple IDPs and user types will be a challenge. It would be great to hear more about your use case.

@G - Thanks for this feedback, personalisation for customers is definitely a part of the vision. Our goal is to tackle the barriers and security, then we can move onto these outcomes.

@Evan Nixon - Thank you for potentially the best comment I have read all year. You are right this button is ridiculous. Its on my radar.

@Christian Olsson - I would like to hear more about this use case. Can you paint me a picture?

@Pascal Kontschan - Some of what you are suggesting I think can be covered by the Organisation sorting by email domains feature, and then with Groups when we extend their capability. In terms of permissions associated at a request level, we are exploring this ask cc: @Jehan Gonsalkorale might be interested in your feedback too.

Thank you everyone for engaging on this topic. I can tell you all are passionate about it, and so are we. I look forward to chatting more.

Cheers, 

Ben.

[Johnson Ip]

Our use case is that we have different components which are supported by different external organisations. The tickets are assigned to the component lead and we had used issue security to restrict the different organisation from seeing tickets assigned to for other component/organisation. Normally we would assign it to the help_desk agent and the JSM email notification will notify their help desk to go and pick up the ticket and reassign it if required. With SSO in place, since the help desk group email can't login in, as a workaround we end up defining the vendors as customer organisation and manually share the ticket with the organisation on top of the component lead automatic assigning mechanism. This is so that their human staff can use their SSO to login and interact with the ticket in the customer portal. Ideally we would like the incidents to be assigned to the team that manages the component and the visibility is restricted to the reporter and the team, this would take care of the scenario that the component lead is on leave and they can't action the ticket unless we get involved and share the ticket with their organisation but I understand that this is not straightly an SSO issue, but an unintended consequence of Atlassian Access being applied to all Cloud instances. 

[Greg D]

@Johnson Ip not sure I fully understand your use-case, but to offer a suggestion, couldn’t you use Automation to automatically set the JSM Organization so that it automatically shares with all of those vendor “customers” and sends the notification on creation (or whenever the component is added if you want that to be the trigger)?