Rhythm 2.0 Specifications

Appearance

CAP-MBR-MEM-014Alert staff to memberships about to expire

Markdown

CAP-MBR-MEM-014

Alert staff to memberships about to expire

Markdown
  • DocumentDraft
  • Product intentProposed
  • ImplementationObserved

Planning

Feature
FEAT-MBR-MEM-05
Key concepts
CON-MBR-MEM-002
Actors
ACT-MBR-006, ACT-MBR-012
Journeys
JNY-MBR-MEM-004
Depends on
CAP-MBR-MEM-005
Related
CAP-MBR-MEM-013, CAP-MBR-MEM-002
Proved by
ATS-MBR-MEM-014

KindCapabilityProduct areaMembershipModuleMemberships, Applications and Membership BillingRevision1

Read atservices-membership 5994c270

Alert staff to memberships about to expire ​

Purpose ​

The renewals team should never learn about an expiry after the fact. Every membership heading for its end date without a renewal should appear among the team's alerts in time to act, and disappear when the member renews or leaves.

How It Works ​

Each morning a sweep looks at every workspace. It finds the principal memberships whose committed term ends within the horizon, 60 days unless the workspace sets otherwise, and that have no later term. Each such membership gets one alert, labelled with the member's name, showing the program, the end date and whether the member auto-renews. The alert goes to whoever holds the renewals responsibility, starting with the member's own chapter and its region, then the workspace. It is due on the term's last day and expires thirty days after. Later sweeps refresh the same alert and clear it once the term leaves the horizon. A renewal or a termination resolves it at once, in the same step as the write. Alerts appear on the console only, with no actions, until the portal is opened to them. Publishing is switched on per environment. This behaviour was built after Andrew's acceptance of Membership and has no record of its own confirming it, so its intent is proposed.

Relationships ​

  • Depends on CAP-MBR-MEM-005 because "no later term" and the business date are the standing rules.
  • Depends on Platform's responsibilities and attention (MOD-PFM-ELG), which store, route and render the alerts.
  • Related to CAP-MBR-MEM-013 because the same "already renewed" rule keeps a term out of a billing run.

The Formal Contract

The narrative above explains; the sections below are authoritative — the rules, scenarios and tests this document binds.

Outcomes
No membership expires without the renewals team having seen it coming.Alerts reach the staff of the member's own chapter and region before the workspace's.
Surfaces
consolejob
Constraints
The sweep publishes in pages of 500 memberships.

Controls

35 controls apply, from the corpus control catalogue.

TC-AVL-002 TC-AVL-003 TC-AVL-004 TC-AZ-001 TC-AZ-003 TC-AZ-004 TC-CHG-001 TC-CHG-002 TC-CHG-003 TC-CHG-004 TC-CRY-001 TC-CRY-002 TC-CRY-003 TC-DAT-001 TC-DAT-002 TC-DAT-003 TC-DAT-007 TC-IAM-006 TC-LOG-002 TC-LOG-003 TC-LOG-005 TC-MON-001 TC-MON-002 TC-MON-004 TC-PI-001 TC-PI-002 TC-PI-004 TC-PI-005 TC-PRV-001 TC-PRV-002 TC-SEC-001 TC-SEC-004 TC-TEN-001 TC-TEN-002 TC-TEN-003

Business Rules

9 rules, 8 to be proved before approval. A rule's product intent is derived from its origin: 0 confirmed by a product decision, the rest inheriting this capability's proposed.

IdRuleKindEnforced atProvenance
01must prove
Proposed
A term is expiring when it belongs to a principal membership, is committed or restated, ends between today and today plus the horizon (60 days by default, settable from 7 to 180), and has no later term.
no proof recorded yet
calculationservicetest
services-membership:modules/memberships/tests/integration/services/expiring-memberships.integration.spec.ts#publishes nothing for a term that already has a successor
02must prove
Proposed
The horizon is measured from the workspace's business date in its own time zone, both ends included, and moves at the workspace's midnight.
no proof recorded yet
calculationservicetest
services-membership:modules/memberships/tests/unit/expiring-memberships.spec.ts#starts on the tenant’s business date, not the UTC date
03must prove
Proposed
Each expiring membership has one alert, labelled with the member's name (else the membership number), carrying the program, the end date, the member and whether they auto-renew, and addressed to the renewals responsibility.
no proof recorded yet
policyservicetest
services-membership:modules/memberships/tests/integration/services/expiring-memberships.integration.spec.ts#addresses the item to membership.renewals, the definition’s default
04must prove
Proposed
An alert is scoped to the membership's units, most specific first, then the workspace.
no proof recorded yet
policyservicetest
services-membership:modules/memberships/tests/integration/services/expiring-memberships.integration.spec.ts#scopes the item by the membership’s chapter and its ancestors, most specific first, then the tenant
05must prove
Proposed
An alert is due at the start of the term's last day in the workspace's time zone and expires thirty days later.
no proof recorded yet
calculationservicetest
services-membership:modules/memberships/tests/integration/services/expiring-memberships.integration.spec.ts#is due at the start of the term’s last day and expires thirty days after it
06must prove
Proposed
A daily sweep publishes each expiring membership, refreshes an existing alert rather than opening another, and clears alerts whose term has left the horizon.
no proof recorded yet
lifecycleservicetest
services-membership:modules/memberships/tests/integration/services/expiring-memberships.integration.spec.ts#refreshes the same item’s facts on the next pass rather than opening another
07must prove
Proposed
A renewal resolves the alert as renewed, and a termination as terminated, in the same transaction as the write.
no proof recorded yet
lifecycleservicetest
services-membership:modules/memberships/tests/integration/services/expiring-memberships.integration.spec.ts#resolves the item renewed in the staff renewal’s transaction
08
Proposed
Alerts are shown on the console only, to staff responsibilities only, with no actions, until the portal is opened to them.
policyservicetest
services-membership:modules/memberships/tests/unit/expiring-memberships.spec.ts#shows on the console only, to staff responsibilities only, with no actions (the portal hold)
09must prove
Proposed
When publishing is switched on, a refusal by Platform's attention service fails the business write it accompanies, so a change never commits with a wrong alert beside it; when it is off, nothing is published.
no proof recorded yet
policyservicedocumented
services-membership:docs/attention.md#3. When items are published and resolved

Scenarios

IdGivenWhenThenProvenance
01Jo's Regular term ends in 40 days and has no renewal.The morning sweep runs, and later staff add Jo's renewal.An alert opens for Jo scoped to Atlanta, its zone and region, then the workspace; the renewal resolves it at once.test
services-membership:modules/memberships/tests/integration/services/expiring-memberships.integration.spec.ts#publishes an open item for a membership whose term ends inside the horizon

The Markdown files under specs/ in rhythmsoftware/rhythm-v2-docs are the canonical source of truth. This reader is a generated, read-only projection of them.

Rhythm Software