MCMMCM DocsEngineering (Internal)
User StoriesMCM-01 — MCM Nexus
v1.2 is unreleased — see v1.1 for the current stable release.

MCM-05 — Request Purchase or Extension

A customer raises a request to purchase MCM or extend their subscription's validity.

MCM-05 — Request Purchase or Extension

← Back to MCM Nexus overview

As a Customer User,
I want to raise a request to purchase MCM or extend my current subscription's validity,
so that I can move from a trial (or an expiring subscription) to continued, paid access.

Acceptance Criteria

  • Purchase and Extension are each raised as their own request type, distinct from the two demo request types (MCM-03, MCM-04).
  • Payment itself is not collected in Nexus — these requests are approved offline once payment/commercial terms are agreed, consistent with the existing flow.
  • A Customer User can view all of their organization's past and pending requests, with status (Pending / Approved / Rejected) and, for rejections, the Nexus Admin's stated reason.
  • A customer whose license is within a configurable window of expiry (e.g. 7 days) sees a prominent "Extend now" prompt on their dashboard.
  • Duplicate pending requests of the same type for the same organization are prevented — the UI surfaces the existing pending request instead of allowing a second submission.
  • On approval of a New Purchase (self-hosted), the customer receives the standard Subscription Activation email unchanged — deployment guides, MCM App username/password, and support/documentation links.
  • On approval of an Extension, the customer instead receives its own, lighter confirmation email (see Email Template below) — no MCM App credentials are re-shared, since the existing credential and deployed instance are unchanged; it confirms only the new end date.

Technical Design

Both request types already exist in mcm-nexus/backend's RequestType enum (NEW_PURCHASE, EXTENSION) and are handled by the existing RequestService/AdminRequestController — no new enum values are needed here, unlike the two demo request types (MCM-03/MCM-04). The only new logic is a duplicate-pending guard added to RequestService.create(...) and a license-expiry-window check in mcm-nexus/frontend that drives the dashboard's "Extend now" prompt. This remains the one request path with no data-sharing disclosure and no automatic entitlement change on submission — approval is always an explicit, offline payment-confirmed Nexus Admin action. On approval, MCM-07 branches by request type: NEW_PURCHASE runs its standard credential-issuance email unchanged, while EXTENSION skips credential issuance entirely and instead sends the lighter confirmation email below via the same shared send-email API (MCM-11).


Email Template

On approval of an Extension, the customer receives this confirmation — distinct from the Subscription Activation email a New Purchase gets, since no credential is reissued:

Subject: Your MCM Subscription Has Been Extended

Dear <Customer>,

Greetings from the MCM Team!

Your MCM subscription has been extended — there is nothing further for you to do.

## Updated Subscription Details

Organization: <Company Name>
New end date: <new end date>

Your existing MCM App credentials and deployed instance are unchanged. You do not need to reinstall, reconfigure, or re-enter anything.

If you have any questions about your subscription, our support team is available to help.

Support Email: mcm@revdau.ai
Documentation Portal: https://mcm.revdau.ai/docs/

Thank you for choosing MCM.

Best Regards,
MCM Team

UI / Frontend Changes

  • Customer dashboard: new prominent "Extend now" prompt shown once the license is within the configurable expiry window (e.g. 7 days).
  • (customer)/requests: request history list shows status (Pending / Approved / Rejected) and, for rejections, the Nexus Admin's stated reason.
  • (customer)/requests/new: Purchase and Extension appear as distinct, separately-selectable options from the two demo request types.
  • Duplicate-pending state: submitting a second request of the same type is blocked in the UI, which instead surfaces the existing pending request.
  • No payment/billing form is shown anywhere in this flow — submission only records intent, consistent with approval remaining an offline Nexus Admin action.

On this page