Skip to main content

PNM periods

A PNM period is the org-wide recruitment window that bounds a cycle of applications. Every PNM record is attached to one period; queues, reports, and the public apply page all gate behavior on which period is currently active. This page walks through the period lifecycle, the period fields you set, and the rules that govern how periods interact with the rest of the module.

Why periods exist​

Periods serve four purposes: they scope every PNM application to a single cycle for clean year-over-year reporting; they gate the public apply page (no active period means the page renders the closed state instead of the form, see PNM public page); they coordinate org-wide rush since periods are always org-wide and all chapters rush together; and they triage close-of-cycle work by auto-inactivating non-crossed PNMs on close.

The three statuses​

A period moves through three statuses:

  • Draft. Created but not yet live. Admins can edit every field. The public apply page treats a draft period as if it didn't exist (i.e., the page is closed).
  • Active. Live. The public apply page accepts submissions for this period, provided the current time is within the period's open/close window.
  • Closed. Done. The public apply page renders the closed state with this period's closed message. Non-crossed PNMs in this period are marked inactive on their underlying membership; crossed PNMs (who became full members) are left alone.

The flow is one-directional in normal operation: Draft → Active → Closed. You can move backwards (e.g., re-open a closed period) but it's rare and unusual.

The fields on each period​

  • Academic year — an integer (e.g., 2026). Combined with semester, this is the human-readable name for the cycle.
  • Semester — one of Fall, Spring, or Summer.
  • Status — Draft, Active, or Closed as described above.
  • Open date — optional timestamp (UTC). When set, the period is treated as "not yet open" until this moment, even if its status is Active. Leave blank to mean "open as soon as Active."
  • Close date — optional timestamp (UTC). When set, the period is treated as past its close window after this moment, even if its status is still Active. Leave blank to mean "open until status flips to Closed."
  • Closed message (Markdown) — content shown on the public apply page when no period is active, drawn from the most recently closed period. Set it on each period so the public page has a coherent closed-state message after this period ends.

The combination of (organization, academic year, semester) is unique — you cannot create two Fall 2026 periods under the same org. If you need to rerun an aborted cycle, close the original and pick the next semester or year.

Creating a period​

  1. Open Org → PNM → Periods.
  2. Click New period.
  3. Set academic year, semester, status, optional open/close dates, and the closed message.
  4. Save.

A period created in Draft is harmless — it doesn't affect the public apply page or any other surface until you transition it to Active.

PNM periods - create form PNM periods - create form

Multiple concurrent periods​

You can have multiple periods in Active status simultaneously (for instance, an early-decision period for transfer students and a regular period for first-years). The apply page resolves to the single active period whose open/close window contains the current time. If multiple active periods overlap in their windows, the resolution picks one and applicants land in it; this is rare and usually means a configuration error.

In practice, run one active period at a time per org. If your operations genuinely need two parallel cycles, talk to support — the simpler model handles the common case cleanly and avoids overlap edge cases.

Closing a period​

When you transition a period from Active to Closed:

  • The period's status is updated.
  • Non-crossed PNMs attached to the period — applicants in any intake state other than completed — have their underlying membership status set to inactive. This keeps the directory clean of stalled applicants from prior cycles.
  • Crossed PNMs (intake status completed) are untouched — they've already been promoted to full membership and are real members of the chapter.
  • The public apply page picks up this period's closed message as the new default closed-state copy.

Closing is the right action at the end of a cycle even if there are stalled applicants in the queue. The auto-inactive behavior is by design — admins shouldn't need to hand-clean each non-crossed PNM. If you want to keep a stalled applicant around for a future cycle, transition them through the intake states (or to rejected) before closing.

Deleting a period​

Periods with no attached PNMs can be deleted outright. Periods that have attached PNMs are protected — deleting them would orphan the PNM records, which is never what you want. The protection surfaces as a conflict response with a clear message: "Period has attached PNM applications. Close the period instead of deleting."

In practice this means most periods, once they have any real submissions, live forever as historical records. This is fine — they are cheap to keep, and they preserve the audit trail.

Cross-period applicant transfer​

There is no built-in cross-period transfer today. A PNM record is permanently attached to the period that was active at the moment of submission. If a stalled applicant resurfaces in a later cycle, the right path is:

  • The new cycle's period is active.
  • The applicant resubmits on the public apply page. A fresh PNM record is created under the new period.

The original PNM record stays attached to the original period as historical context. Admins reviewing the new record can see (via the user account, since both PNMs share an underlying user) that the applicant submitted previously.

Manual database surgery to move a PNM record between periods is possible but unsupported — it bypasses the lifecycle guards and can produce odd reporting.

Naming conventions​

Academic year is a calendar integer — most orgs use the year the cycle begins (Fall 2026 and Spring 2027 are often both academic year 2026, but use whatever your org talks about). Semester is fall, spring, or summer. Reports and exports use the academic year + semester combination as the human-readable period name, so stay consistent in how you name periods.

What you cannot do today​

You cannot run a per-chapter period (all chapters in an org rush together), rename a period in a way that changes its identifying triple of org + year + semester, bulk-transition PNMs between periods, or set a global closed message that overrides the per-period one. Each period's closed message is what the public page shows when that period is the most-recently-closed.

Last verified against v0.62.1 (2026-05-10).