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 Flows
With the existing subscription cancellation flow, 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 "Canceled" status on our platform, assuming the cancellation was complete, while the vendor continued billing due to a failed provisioning synchronization.
For the “existing” cancellation process, please check the following pages:
Storefront Portal with Automatic Cancellation: Cancellations submitted by your Customers - Automatic Flow
Storefront Portal with Cancellation Request: Cancellations submitted by your Customers - Non-Automatic Flow
BSS Portal: Cancellations from BSS
Now, with the updated subscription cancellation flow, 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 existing and updated cancellation processes are used in our platform for different applications.
The existing cancellation process remains applicable mostly for “end of billing period” cancellation types and “partial” subscription cancellations, as well as cancellations of asset and add-on licenses.
The updated cancellation process is essentially used for full subscription cancellations with “immediate” and “past-dated” cancellation types.
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:
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:
“Immediate” and “past-dated” partial cancellations of subscriptions, bundles, assets, and add-ons that are initiated within the BSS portal.
“Immediate” partial cancellations of subscriptions, bundles, assets, and add-ons that are initiated within the Storefront portal.
“End of Billing Cycle” full and partial cancellations for subscriptions, bundles, assets, and add-ons that are initiated within the BSS portal.
“End of Billing Cycle” full and partial cancellations for subscriptions, bundles, assets, and add-ons that are initiated within the Storefront portal.
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 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 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:
Descriptions | BSS Portal Example | Storefront Portal Example | |
|---|---|---|---|
Initial Subscription-State: |
|  |  |
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: | 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: |
|  |  |
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: | 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: |
| ||
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: |
| | |
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: | 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: |
| | |
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: | 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: |
| ||
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: |
| | |
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: | 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: |
| | |
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: | 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: |
| ||
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.