Cancellation Flow

Entering the flow

Following members-data-api/pull/459 we now get a new 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...

• a 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.

• OR step '1 of 3' of the self-service cancellation flow, containing...

  • 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.