🚀 Introducing Products and Entitlements in Jira Service Management

[#1]

We’re excited to launch a much requested Customer Service feature in Jira Service Management: Products and entitlements. This feature is designed to help you tailor support experiences to the specific products and services your customers use. Here’s a quick overview of what you can expect from this new addition, what’s coming next, and how to get started.

Personalize your support based on customer entitlements

With Products and entitlements, you can now associate organizations and customers with their product entitlements, including details such as their support tier, contract renewal date, and more. This allows you to provide personalized support experiences based on the products and services your customers use.

Streamlined help experiences

When customers ask for help in the portal, they can select which product or service they need help with, from a list of only those they are entitled to.

 

Enhanced agent visibility

Agents can easily identify which product a request is about from the issue view, and access detailed entitlement information from customer and organization profiles. This empowers agents to provide more informed and efficient support to your customers.

Getting started

Getting set up with products and entitlements is easy. You’ll need a company-managed Jira Service Management project, with the Customer and organization profiles feature enabled:

1. Head to Project settings. First, enable Customer and organization profiles if you haven’t already. Then, directly below that, enable Products and entitlements.

2. Navigate to the new Products page in the left project navigation sidebar, within Directory, and select Add product at the top left for each product or service you offer.

3. Back on the Products page, select Manage entitlement details and add a detail field for each piece of information you want associated with your entitlements, such as tier or renewal date.

4. Navigate to the profile of any organization or customer you want to create an entitlement for through the Organization or Customer pages in the left sidebar navigation, select Create entitlement, and fill in any entitlement details.

5. Navigate to Project settings > Request types, and add the Entitlement field to any request type that you would like customers to select an entitlement for. You can change the portal display name for the field to something else, such as ‘Product’ or ‘Service’, if you would like to. Keep in mind that if you make Entitlements a required field, any customer with no entitlements won’t be able to submit the request as they will have no field options to choose from.

For more detailed information on how to get started, you can refer to our documentation here.

What's coming next?

We’re already working on some important additions many of you will need to take full advantage of it:

• APIs for syncing entitlement data from your source of truth

• JQL support to enable for automations, queues, and reporting using product and entitlement data

• Direct visibility of entitlement details from the issue view, similar to customers and organizations today

We’re thrilled to bring you this new feature and are eager to hear your feedback. Feel free to get in touch at graubenheimer@atlassian.com with any feedback or questions, or leave feedback in-product at the bottom of Organization or Customer profiles.

Stay tuned for more updates as we continue to enhance the products and entitlements experience in Jira Service Management!

[Rimantas Andrulevičius]

@Gabriel Raubenheimer are there any plans to somehow connect/sync product and entitlement data with assets and/or affected services? 

[Moritz Neuffer]

Very cool, but I also think that this urgently needs to be integrated into the assets. Otherwise there are too many ways to create CIs:
- Assets
- Services (in JSM-Projects, as well as in Compass)
- Products

[Tomislav Tobijas]

This looks very cool and promising! However, I need to support previous comments about integrating this feature with Assets. We've just made one implementation of product 'objects' and supporting relations within Assets and I don't think we'll switch to this anytime soon; as Assets and objects are 'core source' for our org.

[Frank Vandebergh]

I believe this is a nice new feature, but it is missing one big point which is the current premium users already using the Asset Management features.

It feels like these features (and organization management ) are using Assets in the background, but unfortunately there is no possibility for us to link these to our existing other assets.

It would be great if the same could be done as with the "Services" : These services are created in different part of UI, however, they are available within Asset Management as some kind of read-only / "locked" asset. This means we can link the services to other assets. 

We have assets that are linked to customer assets, which are very hard to link to Jira SD "organizations" and now there is another level products that is nicely integrated in the different screens but not usable from asset management. 

If the Organizations and Products could be made available as read-only Asset schemas, similar to Services, that would be very nice.

[Pier-Olivier Tremblay]

Like other said,

Every new features like this one should rely on Assets. The way we interact with the data will be similar no matter what feature we are talking about.

Assets locked schemas like "Services" should become a thing. And maybe in the future let us extend them but have locked default attribute.

Assets is the jewel of JSM. You guys have the chance to build around a cmdb/assets database instead of adding a cmdb to an existing ticketing tool like most other vendor did years ago. Dont' make jsm a bunch of clustered features that all work differently.

Just think about everything that you manage as a CI. CIs go into the CMDB. Can't be simpler than that.

[Helen J]

This could be useful, however the entitlement details should be per product. Our customers may have multiple options - hardware and software. We need to be able to see different information per each, e.g., software would show version, end date, etc; Hardware - status, support level, etc.

[Alex Koxaras _Relational_]

Cool!! This is awesome feature!

[František Špaček _MoroSystems_]

I definetely support others with Assets integration or even better - built on top of assets directly (as e.g. services are).

It would be super cool to have some predefined schemes that we can extend with own attributes (while the original needed are locked, basically same as custom fields and systems field work) or connect them with our schemas and work with them in projects directly like with services.

Building comprehensive database means connecting lots of things from different sources in one place - and that is Assets for most of us. But we have lots of integrations to outside world already, we do not want to create local synchronizations of different parts of Jira into Assets too. Its enough that we already have to create and update JSM organizations from within Assets with help of automations.

[Jonne Riikonen]

This is a great improvement with bunch of potential, unfortunately for us, until Assets links are available, this is not going to help us any further.

We've currently built our whole customer fleet database in to Assets, select the Assets via issue screens and built automation rules to fetch the related data (including other Assets) to corresponding fields and populate the views to our Agents. This is a rather work-heavy approach and does consume lots of resources (processing in Cloud) to run all the automations that trigger each other, but it works. The automations are also a lot to maintain as they're never really bulletproof.

Should it be possible to link the information on the "Organization" -fields and the ones added here as Entitlements/Products, we'd save a huge amount of common resources and also bring lots of added value to the process. It would make the whole package also a lot more attractive and feature-rich for anyone considering to subscribe :)

If anyone at Atlassian is interested to learn more on how we use it, just shoot me a message!

[eb]

I have two IT product I sell, both products not offer same "module" how can I offer different fields for different product ? 

I want fields A,B for product 1 and fields C,D for product 2. They are not same.

Another: can you confirm thought API we can't send an json in body to update all fields of Entitlement of an Org : 

https://developer.atlassian.com/cloud/customer-service-management/rest/v1/intro/#about

[Christian Gick]

Looking forward to using this in Jira Automation! I would like to add a prefix to the tickets to make the product / project visible to which to ticket is associated. Currently pulling this information from assets which seem to come to an end...

[Brock Jolet]

I keep getting 404s when trying to use the API calls.

I also agree with the previous comments about the need for different entitlements for the products and that this should be integrated with Assets, Services, and Automation.

[Bernd Gurn]

I agree to many of the above stated points but in general it´s a good approach to have some additional information regarding the customer for an agent. What i am missing is an alignment of the (customer) user, his company and the related contracts aka SLA to the related services ideally set up as assets. And as the cherry on the cake when the user logged in the portal he/she gets based on the entitlement only related requests offered. Or as an alternative when asked for an entitlement (purchase order/subscription/contract number / id) only the related requests are displayed (plus maybe some common or general ones).

What i need is an option to ask the customer/user with in a step to create a request about his entitlement and based on this information the ticket uses the relevant sla.

[Chris Shillingburg]

A few things I have noticed, one the entitlements on a ticket are solely based on reporter in which it should be the Organization or the option to pick. We have automation that creates tickets and the reporter is an API account that is not associated with any organization. The other thing is this breaks security protocols related to organizations. This is being over-ruled and all users can now manage Organizations, Customers, Products, & Entitlements. There needs to be some type of control around this. I want my employees to be able to see this data but not edit it.