Choosing the right approach to Customer Management in Jira Service Management

[Antonio Valle (G2)]

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

I was thinking in receiving requests via social. You know, brand accounts that say "thank you for your comment, send me a DM so we can manage this" and then the DM becomes an issue in my JiraSM

[Christian Olsson]

Expanding on the idea of having differentiated access rights for customers in portal view.

Using Cloud Jira and Confluence in the company provides multiple benefits.

Developing software that are used by our external customers, one interesting way of expanding Cloud Jira is to deploy the Service Management to run the customer service. The Customer Service is working with external customers, outside of the company. You could then allow the external customer access to Jira Service Management via portal by adding Organisation and add Customers to its organisation.

Such customer can today, via portal, submit tickets to Customer Service. The customer can also see and edit all tickets belonging to the same Organisation. What I would like is to be able to separate read and write permissions on Customer level. This way I can, from an external organisation, have some customers that can interact (read and write) with Customer Support, while other customers from same organisation only can monitor (read) submitted tickets.

BR / Christian

[Benjamin Paton]

@Johnson Ip thanks for the additional info, I think @Greg D offers some good suggestions here. Utilising different projects with organisations is the best way to managed this type of separation. I am not sure why you need to assign a component lead, but maybe this could be achieved with different projects, or automation to set fields which drive queue behaviour. 

@Antonio Valle (G2) thanks for the suggestion. This one is a little bit outside of the scope of this discussion but I have passed it onto the appropriate team. Consideration of new inbound channels is something on the radar (but ironing out email probably comes first).

@Christian Olsson understood. We don't have plans for this level of access control for now, but I have noted your feedback.

[Ryan Geddings]

Couldn't you add something like a json web token that we could pass from our application to allow our users to maintain a single login to JSM? Similar to this https://www.aha.io/support/roadmaps/account/single-sign-on/configure-sso-json-web-token

[Suporte JRetail]

Hi, so i love the new option, but i have a doubt, wha about the older clients? this will work only with new clients or all old and new?

[maximiliano.castrillon]

Commenting to get notices on this and track

[Benjamin Paton]

@Ryan Geddings this is a good suggestion and is something that we will be considering in the future based on demand.

@Suporte JRetail currently these options apply to new customers being created. We will be looking into migration strategies for organisations to get their customers sorted correctly.

[Mike Vitale]

@Benjamin Paton I have a unique scenario which I would love your input on. We have Jira implemented across the organization and are beginning to utilize Service Desk heavily for internal support requests. In this case, JSMs current access and permission schemes work great! 

But we now have a couple new opportunities where we want to allow access into our Help Center:

1. Internal team members in our Production facility who do not have Atlassian access, but could benefit from having access to our help center to submit tickets for things such as reporting Safety concerns, requesting access to company-wide benefits programs, and others. For this team, having an open "sign-up" policy in place can work as we do not have concerns with them having insight and access into our various SM projects and the request types within them.
2. Opportunity #2 is for External Customers (who may want to apply to become partners / product re-sellers for us). We have an extensive application process here which is ripe for conversion to a JSM form and workflow. For these guys, we don't necissarially want them to have the same level of access as our Production team, in fact, we really want to be able to limit their access down to a specific request type within a specific SM project.

Given all of the above, are there any existing solutions to help accommodate what we're trying to accomplish here? 

[Benjamin Paton]

Quick update here, we have release two more of the features from the list. Rollout starts today!

https://community.atlassian.com/t5/Jira-Service-Management-articles/Use-email-domains-to-restrict-external-customer-sign-up-for-your/ba-p/2036372#M1710

[kt.bel]

 @Mike Vitale  We have a similar scenario as what you described.  I was hoping that some of the JSM Global Customer Access permissions could be moved to per project.

[Benjamin Paton]

@Mike Vitale it sounds like you have a hybrid strategy for customer management. 

I recommendation is that you leverage Internal Customer Accounts (also known as Atlassian Accounts) for your Internal team members, I assume they will be using a known list of email domains, so you can utilise the "approved domains" mentioned here. Make sure you set your default product access to ensure these users do not have licenses you do not want them to have (this includes preventing them from being able to see being the scenes of the service desk). If you you have a subset of internal customers who need access to some projects but not others, you can manage permissions with groups.

For your External Customers you can leave the portal open for sign-up and those customers who do not have your internal domain will get appropriate accounts. The projects they should see should be open to anyone with an account.

Unfortunately we do not have the ability to restrict individual requests within projects to certain customers. You will need to have projects for your different cohorts.

[Ivan S.]

@Benjamin Paton , Hello, I have an existential question of how to start with the configuration.

We are a company that serves various clients with various services.

Thinking that I must establish different SLA's and make personalized reporting configurations, what do you think would be the pros and cons of:

Putting together a project and dividing clients by organization? or
Create a project per client?
Thanks!

[Paul Scott]

Anything that helps to manage access to multiple projects is always going to be welcome, especially when like so many other companies we are running both an internal and external service desk function through JSM. 

Organizations will certainly be helpful in restricting access across requests, and if we can add domain approval and memberships to the orgs that would be a huge amount admin work that looks after itself..

[Oliver H]

Hi @Ivan S_

Sorry to hear you're having an existential crisis :P.

JSM is flexible enough for you to choose either option, but from your explanation I would recommend creating a project per client.

You can allow your clients to sign up for accounts, but restrict who can create their own account by email domain, as described here: https://community.atlassian.com/t5/Jira-Service-Management-articles/Use-email-domains-to-restrict-external-customer-sign-up-for-your/ba-p/2036372#M1710

Each project can have its own set of request types and forms, its own SLA configuration, its own reports, its own queues, etc. tailored to best help you support each client.

You can also follow https://jira.atlassian.com/browse/JSDCLOUD-4519 which will allow you to automatically add new accounts into appropriate customer organisations according to email domain, which will in turn allow you to show your customers only the project that are relevant to them.

Of course the flip side of that approach is that your agents will need to navigate across different projects to support different clients.  Depending on your internal team structure and the number of projects, this may be an issue or not.

I hope that was helpful for you.

@Paul Scott, you may also be interested in following https://jira.atlassian.com/browse/JSDCLOUD-4519.  It directly addresses your use case of adding membership to Customer Organisations based on email domain.

Regards,

Oliver

[Ralf]

We are provisioning our internal customers through the AzureAD EnterpriseApp for Atlassian. This is working well. But we don't see any advantage of a real SAML2.0 based SSO, as Microsoft is supporting this only with Edge and Chrome.

Therefor we would appreciate to be able to provide our customers a URL for the JSM portal access, which directly opens the OAuth2 Microsoft login form.

At the moment user enters his Email address, then he gets the a button, that he is set up for SSO, then the Access login form appears, where he needs to remove his Email address from the field and then can click on "Continue with Microsoft".

Access knows, that the user is a managed user and should be able to offer directly the OAuth2 Microsoft login form.

[Greg D]

Any update on whether we will soon be able to edit a portal-only customer's display name in the Customers section of a project?  (please help us)

Also, any developments on the spooky "View Profile" button that @Evan Nixon described?  Would love to have a full, editable profile for Portal-Only customers.  We can live with all the ghosts that we stumble upon for Día de los Muertos, but I'm hoping this could be their last yearly visit to our Jira instances.

[Alex Ziegltrum]

Hey Atlassian-Team,

@Benjamin Paton 

what's the status of the development here? There wasn't an update on this page since Nov 2022.

Cheers, Alex

[Benjamin Paton]

Hello all, 

For anyone following this page, I have just updated some of the roadmap items and timeframes. 

I have also linked in our latest blog regarding the upcoming SSO capability for external customer accounts

Please let me know if you have any questions, 

Cheers, 

Ben.

[Phill Fox]

@Benjamin Paton I have a scenario that I would like to check if the implementation of these changes will have any impact. 

Using the JSM widget in Confluence to capture feedback directly in to JSM we need to setup an open portal. As described on https://support.atlassian.com/jira-service-management-cloud/docs/embed-a-widget-onto-a-web-page/

However the only people with access to the Confluence site are internal staff who whilst not being agents in JSM are known by Atlassian Access. So ideally we should be able to lock this open portal down to just authenticated users. 

I will be at Team 23 and would welcome the opportunity to discuss this with yourself or any member of your team who are present. 

Regards

Phill

[Benjamin Paton]

Hey @Phill Fox

I won't be at TEAM, but I am happy to discuss with you. Is your desire to use the widget, but not have to have the portal set to open?

Unfortunately the architecture of the widget requires the portal to be open because it doesn't support authentication.

Depending on why you want it closed there might be options. An allowlist would allow you to control who can create issues, but the portal would remain visible if someone stumbled upon it.

Cheers, 

Ben.

[Ellen Beentjes]

How would this work related to the new guest accounts in Confluence? Until now we are facing the problem that guest users in confluence (access to one space only) are immediately completely blocked from all knowledge bases in the support desks. Could this be used to create a solution for that issue?

[Greg D]

So looks like in JSM projects via Project settings > Features > Customer service management the awesome new feature of being able to store additional details on a customer has been added!  This is huge.

Will agents soon be able to edit the true portal-only customer's display name in the Customer details section of a project?  Would be good to allow edit of that too.

Also, will the "View Profile" button that @Evan Nixon described soon send us to those details that are found when clicking the hyperlinked name in the customer list instead of a dead, off the beaten track page?  Would be great to be able to access these powerful details from the card on hover that shows up all throughout Jira (the lists, the user fields, etc.).... probably good to get rid of that "Give kudos" button on customer cards too:

[Ash Young]

Hi all!

A quick update for those following this page - JSM external customer SSO is now available for everyone: more information in this post

Getting access today

We’re progressively rolling out to all JSM sites - if you’re looking to skip the queue and enable it today, you can send an email to jps@earlyaccessprogram.atlassian.net with:

• Point of contact name & email
• Atlassian site’s details (e.g. https://<sitename>.atlassian.net)