On this page, you will find an analysis of the full subscription cancellation as well as the license (partial) cancellation processes. You will also find an explanation of both those cancellation flows and where each cancelation process is applicable. Lastly, you can familiarize yourself with four cancellation scenarios detailing successful and failed cancellation processes, user interactions, and expected system notifications.

Differences Between the Previous & Current Cancellation Processes

Formerly, with the previous 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 current 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.

Availability of Both Cancellation Processes

Please note that both the previous and current cancellation processes are used in our platform for different applications.

The previous cancellation process remains applicable for partial subscription cancellations and cancellations of asset and add-on licenses.
The current cancellation process is essentially used for full subscription cancellations.

Applicability of the Previous & Current 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:

The previous 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.
The current 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

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

Scenario 1: Successful Cancellation on Vendor and 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 → BSS subscription status updates to "Cancelled" → Provisioning status updates to "Synchronized". 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: Cancelled; Provisioning status: Synchronized.
A history record is added: "Status is set to {Cancelled} with effective date {effective date}".

Specific Subscription Types:

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. Cancellation of a bundle is prevented 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.
Delete a Subscription: Functionality and implications are being reviewed with the development team. Delete for NCE is currently disabled. It is strongly advised not to use delete as it directly cancels the NCE subscription on Partner Center which is irreversible.

After a subscription cancellation request is successfully completed in specific BSS and Storefront scenarios, a system notification, "Subscription Cancellation Request Completed," is dispatched.

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 (MVP2 - Future Improvement)

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 (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.
Final State: Subscription status: Cancelled; Provisioning status: Synchronized.

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.

Conclusion

These improvements streamline the subscription cancellation process, ensuring better synchronization between our platform and vendor systems, leading to improved customer satisfaction and reduced support inquiries. The new implementation prioritizes vendor provisioning, providing more accurate status updates and minimizing potential billing discrepancies.

Cancellation Processes