Cancellation Flow

Entering the flow

Following members-data-api/pull/459 we get a top level object with key selfServiceCancellation on our ProductDetail type, for example...

... which we use to drive the CancellationCTA component (part of manageProduct.tsx) which, depending on what we get from the API, shows EITHER...

...OR...

...OR nothing if the sub is already cancelled.

Step 1 : cancellationFlow.tsx
/cancel/{urlPart of product}

The above CTAs both link to cancellation flow regardless and then depending on selfServiceCancellation and whether cancellation is configured for the given ProductType in productTypes.tsx, it will EITHER show...

Variation 1

ContactUsToCancel component which displays contact details (filtered by the properties in the new selfServiceCancellation from the API) - see manage-frontend/pull/444. User cannot progress from this point, they can only return to account overview.

Variation 2 - step '1 of 3' of the self-service cancellation flow, containing...

API calls:

make API call out to /cancel/cancellation-date. See cypress tests for the inputs and response body. The response use is outlined used in point 3.

Components:

• the component specified in cancellation.startPageBody of the given ProductType (e.g. membershipCancellationFlowStart.tsx for PRODUCT_TYPES.membership) which typically contains some intro text or in the case of membership for example a list of the benefits the customer will miss if they cancel.
• the available 'reasons' (as a radio group) with the options specified via cancellation.reasons of the given ProductType (e.g. membershipCancellationReasons.tsx for PRODUCT_TYPES.membership) which contains a reason code (used to build the URL for the subsequent steps) but also metadata that can be looked up on the subsequent step(s).
• and optionally (based cancellation.startPageOfferEffectiveDateOptions and whether a chargedThroughDate is available) a choice of effective dates for the cancellation ('today' or 'end of billing period'[chargedThroughDate]). This choice is conveyed to the subsequent steps via CancellationPolicyContext and currently if the customer chooses 'today' they will be put into 'escalated' mode, which means they won't be able to actually complete the cancellation online, but instead a high priority case will be created in Salesforce (see more about that below).

Step 2 : genericSaveAttempt.tsx
/cancel/{product urlPart}/{reason code}

IMPORTANTLY the first thing that happens when this step loads is it calls cancellation-sf-cases-api (see wiki/Proxying-API-Gateway-Lambdas) to create/resume a case in Salesforce to track the users journey through the cancellation flow (the Salesforce ID of the case is available from then on via CancellationCaseIdContext).

Then if cancellation.flowWrapper of the given ProductType is specified (e.g. GW & Voucher use physicalSubsCancellationFlowWrapper) it will make calls to holiday-stop-api and potentially delivery-records-api to check for outstanding credits which will need to be manually refunded. If any are returned then this can put the flow into 'escalated' mode.

Once the above is done, it presents the page itself and based on the reason selected includes...

• some intro copy (which aims to 'save' the customer and prevent cancellation)
• if in 'escalated' mode at this point, an extra paragraph explaining that
• a free-text feedback box (unless skipFeedback: true on the cancellation reason metadata), which can be submitted directly via the Submit feedback button, which will make a further call to cancellation-sf-cases-api which updates the 'Description' on the SF case. The free text will still be submitted if the customer clicks Confirm cancellation (the GA event action will be submitted or submitted silently respectively), but we still present the dedicated 'Submit feedback' button on its own in-case the customer wants to explain a problem / vent without actually cancelling.

Clicking Confirm cancellation will navigate to the final step, which actually performs the cancellation...

Step 3 : executeCancellation.tsx
/cancel/{product urlPart}/{reason code}/confirmed

Before this page displays...

• if in 'escalated' mode it will simply finalise the Salesforce case to mark it with the reasons it's escalated in the subject (Online Cancellation MANUAL INTERVENTION REQUIRED - PLUS Requested Effective Today, Outstanding Holiday Stop Credits and/or Outstanding Delivery Problem Credits) and sets the Status to New and the Priority to High` (the case assignment rules in Salesforce ensure it ends up in the correct queue, as per convention).
• if not, it will make the POST to members-data-api (see wiki/Proxying-members-data-api) to actually perform the cancellation and once complete will do a GET on members-data-api targeting just that subscription to ensure cancelledAt:true then lastly updates the Salesforce case accordingly Subject: "Online Cancellation Completed" or Subject: "Online Cancellation Error" (if cancelledAt doesn't show true).

... then depending on the above displays some copy accordingly (and potentially up-sell in the form of the resubscribeThrasher.tsx) or error message if applicable.