This page provides an analysis of the updated full-subscription cancellation process. It includes an explanation of the cancellation flow and outlines three different scenarios that illustrate both successful and unsuccessful cancellations. These scenarios detail user interactions and the expected system notifications throughout the process.

Following the 3.28.174 release, we implemented an updated cancellation process for full subscription cancellations that is more reliable and transparent than the existing one. This updated flow prioritizes vendor provisioning, providing more accurate status updates and minimizing potential billing discrepancies since it keeps users informed if there is an issue during the cancellation, whether it occurs on our platform or the vendor's platform. As a result, users will know with certainty if the cancellation has been successful on both platforms or not and how to resolve the problem (if an error occurs) and successfully cancel their subscription.

Updated Cancellation Flow

With the updated subscription cancellation process, our system now prioritizes cancellations on the vendor’s platform before implementing them on our platform. This change leads to a more reliable and transparent cancellation experience, ensuring that the actual statuses are clearly displayed on both our platform and the vendor's platform.

Applicability of the Updated Cancellation Process

This section of the page explains where the updated cancellation process is applied. Specifically:

The updated cancellation process applies to full cancellations for all Service Managers and their respective subscriptions (paid and trial) and bundles requiring provisioning. Specifically, this covers:

“Immediate” or “past-dated” full cancellations of subscriptions (and bundles) that are initiated within the BSS portal.
“Immediate” full cancellations of subscriptions (and bundles) that are initiated within the Storefront portal.
Full cancellation requests of subscriptions (and bundles) with an immediate or past effective date that are initiated within the Storefront and are accepted within the BSS portal.

Crucially, all existing checks and validations performed before the cancellation process remain unchanged.

Cancellation Scenarios and Handling FOR THE UPDATED CANCELLATION

This section describes the different scenarios that can occur during the updated cancellation process (of full subscription cancellations) and how they are handled in both the Storefront portal and the BSS portal.

1ST SCENARIO Successful Cancellation on the Vendor Platform and Our Platform

Let’s assume that a Storefront or BSS user initiates a full subscription cancellation based on the following specifications and the cancellation is successful:

	Descriptions	BSS Portal Example	Storefront Portal Example
Initial Subscription-State:	Subscription status: Active, Inactive, or Suspended. Provisioning status: Synchronized.
Cancellation Type:	Only for “Immediate” or “Specific Date” (in the past).
Process:	User triggers cancellation → Provisioning status updates to "In Progress" → During this phase, no provisioning or billing actions can be performed. This applies both to BSS and Storefront → Cancellation on the vendor platform is successful → BSS subscription status updates to "canceled" → Provisioning status updates to "Synchronized".
System Notifications: (In the form of ribbons, toasters)	During the actual cancellation process, the user who initiated the cancellation views a cyclical loader until the cancellation is completed on all platforms, while another user who views the same subscription will witness an informative ribbon stating that a provisioning action for this subscription is ongoing.
Final Subscription-State:	Subscription status: canceled. Provisioning status: Synchronized.
Cancellation Pop-Up Window: (Pop-ups are used to confirm actions and display success/failure messages.)	Informs the user of the successful cancellation.
System Email Notifications: (In the form of emails)	After a subscription cancellation is successfully completed, a system email notification, "Subscription Cancellation Request Completed," is dispatched.	The email is dispatched when a BSS user accepts a cancellation request that has been initiated from the Storefront and has been completed successfully.	The same email is dispatched when a Storefront user has initiated and successfully completed a cancellation for a subscription that is automatic and does not require the approval of a BSS user.
History Record:	A History record is added: "Status is set to {canceled} with effective date {effective date}".		N/A
Notes:	Subscriptions with Add-ons: Both the main product and the add-on subscriptions are updated to "canceled" and "Synchronized" upon successful completion. Trial Subscriptions: Follow the same flow. Bundle Subscriptions: Follow the same flow. Backordering Subscriptions: Cancellation is allowed only via Tenant Reseller Organization. The same flow is followed. Invoicing: No changes to invoicing procedures.

2ND SCENARIO Failure of Cancellation on the Vendor Platform

Let’s assume that a Storefront or BSS user initiates a full subscription cancellation based on the following specifications, and the cancellation experiences a failure at the platform of the vendor or during the communications between the two systems (i.e., timeout):

	Descriptions	BSS Portal Example	Storefront Portal Example
Initial Subscription-State:	Subscription status: Active, Inactive, or Suspended. Provisioning status: Synchronized.
Cancellation Type:	Only for “Immediate” or “Specific Date” (in the past).
Process:	User triggers cancellation → Provisioning status updates to "In Progress" → During this phase, no provisioning or billing actions can be performed. This applies both to BSS and Storefront → Cancellation on vendor fails (due to client, server, or process errors) → BSS subscription status returns to its prior status before the cancellation. → Provisioning status returns to its prior status before the cancellation. → User is informed with a Vendor type error explaining the issue. → The subscription History record logs the Vendor error about the failed cancellation process.
System Notifications: (In the form of ribbons, toasters)	During the actual cancellation process, the user who initiated the cancellation views a cyclical loader until the cancellation is completed on all platforms, while another user who views the same subscription will witness an informative ribbon stating that a provisioning action for this subscription is ongoing. Moreover, in the event of an error, the users will be informed accordingly via respective pop-up messages (BSS & Storefront) and/or via the subscription's History records (BSS), for the Vendor error message.
Final Subscription-State:	Subscription status: returns to the previous status before the cancellation initialization. Provisioning status: returns to the previous status before the cancellation initialization.
Cancellation Pop-Up Window: (Pop-ups are used to confirm actions and display success/failure messages.)	It informs the user of the unsuccessful cancellation with an error message displaying the vendor-provided error description. The user can either retry and/or contact the vendor to complete the cancellation.
System Email Notifications: (In the form of emails)	Currently, no notification email is available to inform users about a failed subscription cancellation. The information is only available via the cancellation pop-up windows (BSS & Storefront) and the subscription History records (BSS).	N/A	N/A
History Record:	A History record is added: “Subscription failed to cancel due to Provisioning Error. Please try to cancel the subscription again.” This means that the error was from the Vendor platform, and you have the option to retry canceling the subscription. Otherwise, you can also contact the vendor to try to complete the cancellation.		N/A
Notes:	Subscriptions with Add-ons: Both the main product and the add-on subscriptions return to their previous (Subscription & Provisioning) statuses upon an unsuccessful cancellation. Trial Subscriptions: Follow the same flow. Bundle Subscriptions: Follow the same flow. Also, if one sub-subscription fails, all remain in their initial (pre-cancellation) states. Backordering Subscriptions: Cancellation is allowed only via Tenant Reseller Organization. The same flow is followed, meaning that upon an unsuccessful cancellation, the subscriptions return to their previous (Subscription & Provisioning) statuses. Invoicing: No changes to invoicing procedures.

3RD SCENARIO Successful Cancellation on the Vendor Platform with a Failure on Our Platform

Let’s assume that a Storefront or BSS user initiates a full subscription cancellation based on the following specifications, and the cancellation is successfully completed on the vendor platform but experiences a failure at our platform:

	Descriptions	BSS Portal Example	Storefront Portal Example
Initial Subscription-State:	Subscription status: Active, Inactive, or Suspended. Provisioning status: Synchronized.
Cancellation Type:	Only for “Immediate” or “Specific Date” (in the past).
Process:	User triggers cancellation → Provisioning status updates to "In Progress" → During this phase, no provisioning or billing actions can be performed. This applies both to BSS and Storefront → Cancellation on vendor succeeds → Failure on our platform occurs → BSS subscription status returns to its prior status before the cancellation. → Provisioning status returns to its prior status before the cancellation. → User is informed with a Platform type error explaining the issue. → The subscription History record logs the Platform error about the failed cancellation process.
System Notifications: (In the form of ribbons, toasters)	During the actual cancellation process, the user who initiated the cancellation views a cyclical loader until the cancellation is completed on all platforms, while another user who views the same subscription will witness an informative ribbon stating that a provisioning action for this subscription is ongoing. Moreover, in the event of an error, the users will be informed accordingly via respective pop-up messages (BSS & Storefront) and/or via the subscription's History records (BSS), with our Platform error message.
Final Subscription-State:	Subscription status: returns to the previous status before the cancellation initialization. Provisioning status: returns to the previous status before the cancellation initialization.
Cancellation Pop-Up Window: (Pop-ups are used to confirm actions and display success/failure messages.)	It informs the user of the unsuccessful cancellation with an error message displaying our platform-provided error description. The user must contact our support team to complete the cancellation.
System Email Notifications: (In the form of emails)	Currently, no notification email is available to inform users about a failed subscription cancellation. The information is only available via the cancellation pop-up windows (BSS & Storefront) and the subscription History records (BSS).	N/A	N/A
History Record:	A History record is added: “The subscription cancellation process has encountered an error on our Platform. Please contact your administrator”. This means that the error was from our platform, and you must contact our support team to complete the cancellation.		N/A
Notes:	Subscriptions with Add-ons: Both the main product and the add-on subscriptions return to their previous (Subscription & Provisioning) statuses upon an unsuccessful cancellation. Trial Subscriptions: Follow the same flow. Bundle Subscriptions: Follow the same flow. Also, if one sub-subscription fails, all remain in their initial (pre-cancellation) states. Backordering Subscriptions: Cancellation is allowed only via Tenant Reseller Organization. The same flow is followed, meaning that upon an unsuccessful cancellation, the subscriptions return to their previous (Subscription & Provisioning) statuses. Invoicing: No changes to invoicing procedures.

Distinguishing Vendor from Platform Cancellation Errors in the Subscription “History” Log

As discussed in all the scenarios analyzed above, all cancellation actions—whether successful or unsuccessful—are recorded as informative entries in the subscription view pages under the History log section in the BSS portal. Since BSS users may be unsure about the sources of cancellation error messages, whether they originate from the Vendor or our Platform, the History log serves as the safest and most straightforward method for identifying the source of each cancellation error.

Vendor Related Errors -> Have inside the recorded log line the error message: “Subscription failed to cancel due to Provisioning Error. Please try to cancel the subscription again.“. Here, the user can either retry to cancel the subscription and/or contact the vendor.
Platform Related Errors -> Have inside the recorded log line the error message: “The subscription cancellation process has encountered an error on our Platform. Please contact your administrator“. Here, the user must contact our support team to complete the cancellation.

Distinguishing Canceled Subscriptions Between the Existing and the Updated Cancellation Processes

Prior to the 3.28.174 release, all that, failed-to-provision, canceled subscriptions (canceled through the existing process) had a combination of a "Canceled" Subscription Status and a "Failed" Synchronization Status on our platform. Following the 3.28.174 release, canceled subscriptions (those partially canceled, or those canceled at the End of Billing Period via the existing process) will continue to retain this combination of statuses. However, subscriptions canceled through the updated process will have a "Canceled" Subscription Status and a "Synchronized" Synchronization Status.

Full-Subscription Cancellation Process