Introducing New Cloud Identifiers

Atlassian is focused on being a cloud-first company, both for our core products and the systems that integrate them. On this journey, we are also looking to improve our billing experience by replacing our existing purchasing system with a new C ommerce C loud P latform (CCP).

We will migrate in a phased approach, starting with a move away from S upport E ntitlement N umber (SEN) as a unique identifier and switch to other identifiers that are a better fit for the subscription and provisioning needs of our cloud-based products. SEN is based on our server business and has been used as both the unique identifier of a product and the unique identifier of the container that holds the product (site or org).

What is changing?
For our cloud products, the first key change we are planning is the replacement of S upport E ntitlement N umber ( SEN ). We are replacing the SEN with these relevant new identifiers:

New identifier How will it be used? New value Format
CloudID To identify a site (ex: myStuff.atlassian.net) Today cloud uses SEN to identify the site (e.g site.atlassian.net). In the future, cloudID will be used to identify the cloud site. UUID: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
EntitlementID To identify an entitlement Today we don’t depend on the product SEN and rely only on site SEN for support and invoicing purpose. In the future, all cloud products and services will have their own unique entitlementID which will make it easier to manage and support. E-XXX-XXX-XXX/ UUID : XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX

What are the benefits of this change?
Unlike SEN where the correlation between product and site prohibits flexibility, the introduction of new identifiers will allow customers to pay for products associated with the same site in different ways (i.e. different payment methods and different billing cadences).

The current product SEN construct enforces a common identifier for both subscription and what you are entitled to (features/product) after paying for the subscription. This creates hindrance in managing bundles with more than one products. Moving to the new identifiers, like entitlementID , will also allow for having a dedicated identifier for product entitlement even with a common subscription, like a bundle.

When are these changes happening?
We plan to make these new identifiers available in October 2021. While all the consumers of SEN are encouraged to adopt these new identifiers, SENs will continue to co-exist to facilitate the transition without any disruption. We’ll be sharing more details on the transition plan and how we plan to support partners in the coming months.

What do I need to do?
As we work on identifying all the APIs that depend on SEN and their impact, we recommend that partners document all the systems and downstream implications of this change on their end. We’ll work closely with the partner community to assess the impact and how we can support this transition.

For additional context on the Cloud Commerce Platform journey, qualifying Marketplace Partners* can reference the Partner Portal blog post.

Any Marketplace Partner with at least 1 paid-via-Atlassian app qualifies for the Partner Portal. To request access, submit a ticket here.

Frequently Asked Questions:

Question Details
How will the new identifiers impact the my.atlassian.com and support.atlassian.com experience? SEN will be continue to supported for all existing products my.atlassian.com and support.atlassian.com until we move to a new experience for customer landing on CCP.
Will the experience for my customers using my.atlassian.com change? Until the new experiences are available to you and your customers, My.atlassian.com will fully support SEN. As we transition to the new billing platform (and new experiences), the new experiences will support the new identitfiers. More details will be communicated prior to launch.
Will there be any changes to existing cloud sites? No functional or billing related changes to Cloud sites will take place. However, if you do use the SEN to identify a site then you need to transition to the new identifier (CloudID) once it is made available.
What will happen to existing Cloud sites? All Cloud sites would be supported with new ID CloudID alongside SEN until the transition is complete
How will I submit support tickets without a SEN? We will continue to support the SEN for support for the foreseeable future in addition to the new identifier.
What changes can I expect to see on my existing cloud renewals? All cloud renewals will include the new identifier along with SEN to enable a smooth transition before we move away from SEN identifiers completely
When will we start to use the new identifiers for quotes? The new identifier will have to be used when your entitlements are migrated to the new platform. More details will be communicated prior to that time.
When will Marketplace partners need to make changes to their apps? Marketplace partners should start to utilize new IDs (in place of SEN) before end of the year (2021). In order to ensure a smooth transition new IDs will be made available alongside SEN in the interim.
What happens when I have a recurring order/monthly - what changes, if any, can I expect to see? There is no change in the behaviour of recurring order/monthly (or even annual) with introduction of these new IDs.
When can we expect to see changes to the API or JSON files? As we work on identifying all the APIs that depend on SEN and their impact, we recommend that you document all the systems and downstream implications of this change on their end. We’ll be working closely with you to assess the impact and will reach out to you in advance for any API specific changes that you may need to make.
10 Likes

@DivyanshuKumar - does this mean that future evaluations for Cloud apps could be exactly 30 days, rather than the 30-60 days currently offered? My understanding is that the current approach was to align the parent product (Jira) billing cycle with the Marketplace app’s billing cycle. Is this contemplated?

5 Likes

I guess this will result in new fields to the Licenses and Transations API. Is there a way to play around with that?

1 Like

Some questions:

  1. Will Server and DC inherit new EntitlementID or will they still need to be tracked uniquely by SEN? It would ideal if all hosting types use a common ID.

  2. Will EntitlementID be unique for each product and hosting type combination in Cloud?

1 Like

Thanks for sharing, one question regarding

Does this mean the following scenarios will be possible:

  1. As a customer I have Jira on an annual billing plan, App 1 monthly and App 2 annually?
  2. As a customer I have Jira or Confluence on a monthly plan, and Apps on an annual billing cycle?
3 Likes

@adam Thanks for your question. The new cloud platform will enable support for decoupling billing from sites and provide the flexibility to co-bill for subscriptions which have same frequency (eg. monthly with monthly) and common billing parameters( eg. shipping address and payment method). These capabilities are still being defined and built for the new cloud platform.

@david.toussaint Thanks for your question and highlighting the dependency. We are currently working on evaluating and identifying all the APIs that depend on SEN and their impact. We recommend that you document all the systems and downstream implications of this change on your end. We’ll be working closely with you to assess the impact and will reach out in advance for any API specific changes that may need to be made.

@DinoStamatiou Thanks for your questions. Here are the responses to 1 & 2 :

  1. The new identifiers have been introduced only for cloud products and NOT for server and DC products that will continue to rely on SEN.
  2. Each cloud product will have a unique entitlement ID in place of existing product SEN and each site will have a Cloud ID in place for existing site SEN.

@nils Thanks for your questions. The new cloud platform will enable support for decoupling billing from sites and provide the flexibility to co-bill for subscriptions which have same frequency (eg. monthly with monthly) and common billing parameters( eg. shipping address and payment method). These capabilities are still being defined and built for the new cloud platform.

@DivyanshuKumar are you asking us to document your APIs for you?

1 Like

@boris Thanks for your question. We are currently working on evaluating and identifying all the APIs that depend on SEN and their impact from our end. For now we encourage that you identify the anticipated impact of this change on your end as well. We’ll be working closely with you on ensuring there is no disruption and will reach out in advance for any API specific changes that may need to be made.