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.

Differences Between the Existing & Updated Cancellation Flow

Formerly, with the existing implementation of subscription cancellation, the system first processed the cancellation on our platform and then executed the provisioning with the vendor. This sequence occasionally resulted in discrepancies between the status displayed on our platform and the actual status with the vendor, leading to customer confusion and potential billing issues. For instance, an accountant might observe a "Cancelled" status on our platform, assuming the cancellation was complete, while the vendor continued billing due to a failed provisioning synchronization.

Now, with the updated implementation of subscription cancellation, the system actually reverses the cancellation process sequence by prioritizing vendor provisioning before updating our platform. This change provides a more reliable and transparent cancellation experience.

Applicability of the Existing & Updated Cancellation Processes

As mentioned earlier, both cancellation processes are utilized for different cancellations within our platform. Therefore, this section of the page explains when each cancellation process is applied. Specifically:

1. The existing cancellation process applies mostly to partial cancellations (of licenses) for all Service Managers and their respective subscriptions (paid and trial), bundles, assets, and add-ons requiring provisioning. Specifically, this covers:

   1. “Immediate” and “past-dated” partial cancellations of subscriptions, bundles, assets, and add-ons that are initiated within the BSS portal.

   2. “Immediate” partial cancellations of subscriptions, bundles, assets, and add-ons that are initiated within the Storefront portal.

   3. “End of Billing Cycle” full and partial cancellations for subscriptions, bundles, assets, and add-ons that are initiated within the BSS portal.

   4. “End of Billing Cycle” full and partial cancellations for subscriptions, bundles, assets, and add-ons that are initiated within the Storefront portal.

   5. Partial cancellation requests of subscriptions, bundles, assets, and add-ons with an immediate or past effective date that are initiated within the Storefront and are accepted within the BSS portal.
      

2. 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:

   1. “Immediate” or “past-dated” full cancellations of subscriptions (and bundles) that are initiated within the BSS portal.

   2. “Immediate” or “past-dated” full cancellations of subscriptions (and bundles) that are initiated within the Storefront portal.

   3. 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 for both cancellation flows.

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:

		BSS Portal Example	Storefront Portal Example
Initial Subscription-State:	Subscription status: Active, Inactive, or Suspended. Provisioning status: Synchronized or Failed.
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, and additionally, no add-on actions will be available. This applies both to BSS and Storefront → Cancellation on the vendor platform is successful → BSS subscription status updates to "Cancelled" → 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: Cancelled. Provisioning status: Synchronized.
Cancellation Pop-Up Window:	Informs the user of either successful cancellation completions or errors.
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.	✅	✅
History Record:	A History record is added: "Status is set to {Cancelled} with effective date {effective date}".	✅	N/A
Notes:	Subscriptions with Add-ons: Add-on actions are disabled during cancellation provisioning. Both main product and add-on subscriptions are updated to "Cancelled" and "Synchronized" upon successful completion. Trial Subscriptions: Follow the same flow. Bundle Subscriptions: Follow the same flow. A bundle cannot be canceled if any sub-subscription is "In Progress." Backordering Subscriptions: Cancellation is allowed only via Tenant Reseller Organization. The same flow is followed. Invoicing: No changes to invoicing procedures.

Scenario 2: Failure of Cancellation on Vendor

• Initial State: Subscription status: Active, Inactive, or Suspended; Provisioning status: Synchronized or Failed.

• Process: User triggers cancellation → Provisioning status updates to "In Progress" → Cancellation on vendor fails (due to client, server, or process errors). No provisioning or billing actions can be performed and additionally no addon actions will be available. This applies both to BSS and STR

• Final State: Subscription status: Initial status; Provisioning status: Initial status.

• The reason for provisioning failure is displayed to the user.

• For bundle subscriptions, if one sub-subscription fails, all remain in their initial states.

User Notifications:

• BSS: A pop-up displays the vendor-provided error description. A history record is added: "Subscription failed to cancel due to Provisioning Error. Please try to cancel subscription again."

• STR: A toaster message and a pop-up display the vendor-provided error description.

Scenario 3: Failure of Cancellation on Vendor

• Process: User triggers cancellation → Provisioning status updates to "In Progress" → Cancellation on vendor fails (e.g., subscription already cancelled or deleted). No provisioning or billing actions can be performed and additionally no addon actions will be available. This applies both to BSS and STR.

This scenario is planned for a future release (MVP2).

Scenario 4: Successful Cancellation on Vendor, Failure on Our Platform

• Initial State: Subscription status: Active, Inactive, or Suspended; Provisioning status: Synchronized or Failed.

• Process: User triggers cancellation → Provisioning status updates to "In Progress" → Cancellation on vendor successful → Platform failure occurs. No provisioning or billing actions can be performed and additionally no addon actions will be available. This applies both to BSS and STR.

• Final State: Subscription status: Initial status; Provisioning status: Initial status.

User Notifications:

• BSS/STR: A pop-up displays the platform-provided error description. A history record is added (BSS): "The subscription cancellation process has encountered an error on our Platform. Please contact your administrator."

History Section on Cancellation Actions

All cancellation actions register an informative line inside the History section of each subscription.

Info About UI Elements:

• Pop-ups are used to confirm actions and display success/failure messages.

• Toaster messages in Storefront are used for brief notifications.

• Ribbons are displayed on subscriptions "In Progress".

• The subscription status becomes “In Progress” when the cancellation is initiated, and it either turns to “Canceled” once the cancellation is completed successfully or the status previous to the cancellation action if the cancellation action was not completed successfully or “Pending for Cancel” if the cancellation is going to be completed at a future date. Also, the provisioning sync status remains “Synchronized” when the cancellation action is completed successfully; otherwise, it might remain as it was before the cancellation action or change to .

• Failed Synch Status and Retry Button: No changes were made. The retry button relates to the provisioning action that caused the failure.

• Subscriptions in Synch Status In Progress: Existing platform behavior is maintained: no provisioning or billing actions are available. Billing services ignore subscriptions in this status.
  
  

FOR RN Value: This improvement streamlines the subscription cancellation process, ensuring better synchronization between our platform and vendor systems, leading to improved customer satisfaction and reduced support inquiries. The updated cancellation implementation prioritizes vendor provisioning, providing more accurate status updates and minimizing potential billing discrepancies.