Membership Application
What It Is
A membership application records a request to enter or change a membership relationship through a configured application process. It connects Membership’s program and package choices to a submission reviewed by the Submissions engine. The record identifies the applicant, the operation requested, any membership concerned, chosen units and the delivered decision.
The process describes what the association is reviewing. It names the program, offered packages, submission definition and whether review is required. The application then supplies the particular request and its result. This division lets Membership act on a decision without implementing its own form, reviewer assignments or review stages.
What It Is Not
The typed application does not contain or own the submission’s full review experience. Submissions owns that record and delivers its decision. An approval can lead to a Commerce order, but the application remains a record of the request and decision rather than becoming the order or the membership. Rejection of a reserved request cancels pending terms and retains the membership; it does not automatically erase the holding.
How It Is Used
Administrators configure a process for the offer under review. A reviewed package makes purchase preparation require approval unless the purchase identifies an approved application. Membership records a delivered decision once, accepts an explicitly superseding decision and ignores a conflicting later delivery that does not name the recorded predecessor.
Approval of a purchase process prepares the package and required chapter dues through the checkout preparation path. Membership records the placed order and acknowledges successful handling to Submissions. Preparation or placement refusal leaves the decision unacknowledged for another delivery. These exchanges currently depend on unwired external ports, and ordinary application intake is also incomplete. Staff can inspect existing applications; officers use the scope of the linked membership, while an application without a membership is available only to workspace-wide readers.
Its Facets
Application process. The process identifies the configured offer. Version-checked updates retain omitted fields and package lists rather than requiring whole-record replacement.
Kind and outcome. The request kind identifies the membership operation, while the outcome describes the intended consequence of approval. Affiliation-change processes do not place a dues order through the current decision path.
Window and eligibility binding. Opening dates, closing dates and eligibility references are stored. The date order is validated, but runtime admission does not currently enforce these settings.
Outcome parameters. Timing and package options have a bounded, validated shape. The decision handler currently uses the application’s package and process kind rather than applying these stored options.
Chosen units and assigned contacts. Ordered chapter choices feed purchase preparation. Named organizational contacts identify assigned seats associated with organizational membership.
Decision. The external result and its recording trail determine whether the application is decided, awaiting the applicant, withdrawn or closed. A decision identity also makes repeated delivery distinguishable from a new ruling.
Order and acknowledgement. The order reference connects approval to its purchase work. Acknowledgement records completion of the exchange separately from whether Commerce has fulfilled the membership period.
How It Relates
Submissions supplies intake, review and decisions. Membership supplies the typed request and the membership-specific consequences. Commerce manages purchase placement and fulfilment. Existing membership references support scoped reads, while assigned contacts connect organizational applications to dependent memberships.
What It Could Become
The product should complete intake and the external order and acknowledgement ports before presenting this as a working application journey. It should also settle enforcement of process windows, eligibility and stored outcome parameters. Any decision to remove a rejected applicant’s retained membership needs an explicit lifecycle policy rather than being inferred from the rejection itself.