Introducing New Cloud Identifiers

Announcements
, ,
1

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.
12 Likes
2

@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
3

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

2 Likes
4

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?

2 Likes
5

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
6

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

2 Likes
7

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

1 Like
8

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

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

10

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

2 Likes
11

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

12

@DivyanshuKumar can you provide details on how long the SEN and CloudID would run in parallel till you deprecate SEN? Also, are you going to deploy the CloudID retroactively for all active cloud licenses or only when they renew?

1 Like
13

@DinoStamatiou Thanks for your question. SENs would continue to run in parallel until all downstream systems and and consumers have completed the changes to understand and validate the working of the new Identifiers alongside SEN at which point the dependency on SEN would not exist anymore. From the point of deployment of these changes Cloud IDs would be available alongside site SEN for all active historical as well as new cloud sites that are created. Similarly Entitlement IDs would be available alongside product SEN for all active historical as well as new cloud product activations in a site. Please let us know if you have more questions.

14

Is it possible to get hold of we should be directing customers to find the cloud ids? Ie. what’s the customer messaging with this?

15

Hi @DivyanshuKumar what is the status of this initiative in terms of timelines? We are conducting an internal review of the impact of this and it is colossal. Who is going to reach out to us to discuss these impacts on our processes?

1 Like
16

Thanks for your question @danielwester Cloud IDs would be made available alongside site SEN and site URL until the transition is complete. Please watch out for the communication from our end shortly about more updates on the SEN replacement initiative and the timelines. Thanks.

17

@DinoStamatiou Thanks for your question and highlighting the concern. We are going to shortly publish more updates on the SEN replacement initiative and the corresponding timelines. Please watch out for the same.

18

Hi @DivyanshuKumar, will SEN remain for Data Center and it appears that the format of the new EntitlementID will be a concatenation with CloudID…can you confirm? Lastly, any updates on this initiative in general?

19

@DinoStamatiou SEN will continue to be used for Data center and server products and the new identifiers are only being introduced for cloud products. As mentioned in the blog above the format of the new entitlement identifier is not a concatenation. It will be a human readable number of the format E-XXX-XXX-XXX which will be used for billing purposes by all the stakeholders instead of SEN. However the new entitlement identifier will also have a UUID format (non-human readable) which will be used for the purpose of underlying system/API reference but not exposed for billing purposes. Please watch out for our latest blog to be published on new identifiers for SEN in a few days from now. Thanks.

20

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.