Skip to main content

Modules Reference

GreekManage is organized around modules. Each module is a self-contained feature area — its own sidebar items, its own background jobs, its own pricing line, and its own enable / disable switch. This page is the index: a one-paragraph summary of every module, the four always-on surfaces that are not modules, and how enablement is enforced under the hood.

The two pieces of nuance worth knowing up front:

  1. The platform distinguishes core modules (always on, free, not licensable) from optional modules (licensable, toggled by a platform admin per organization). Operations and Community are the most commonly enabled optional modules, but they are still optional.
  2. Disabling a module hides surfaces and blocks endpoints — it does not delete data. Re-enabling the module restores access to everything that was there before.

Optional / licensable modules​

Each module reference page is a hub. It links out to the post-enable runbook, the org admin deep dives, and the member walkthroughs for that feature area.

Core (always-on) surfaces​

Four surfaces are part of the core platform and are not licensable. They do not appear in the modules picker because they cannot be turned off:

  • Chapters — chapter detail, roster, settings
  • Regions — regional grouping, regional admin dashboard
  • Members — the org-wide member directory, profile fields, custom fields, saved views
  • Settings — the org settings shell itself

Notifications and audit logging run alongside these core surfaces. They are not exposed as separate modules; they are always on and configured per-org from within Settings.

Three-layer enforcement​

When a module is disabled for an org, GreekManage blocks it at three layers so the surface is invisible across web, mobile, API, and background work:

  1. Sidebar guard. The navigation hides the entries belonging to the disabled module, so members and officers never see the link.
  2. API middleware. Requests to a disabled module's endpoints return a 403 with a "module disabled" error, even if a user reaches the URL directly.
  3. Background workers. Scheduled jobs check the per-org module table before running. If the module is off, the job no-ops for that tenant.

The same enablement record drives all three layers, so toggling once is enough — there is no separate "deploy to sidebars" step.

Module lifecycle​

Enabling. A platform admin flips the module on for a specific org. The change is immediate; affected users may need to refresh once to see new sidebar items.

Disabling. Same surface, opposite direction. Sidebar items disappear, API endpoints return 403, scheduled jobs skip the tenant. Data is preserved — every record that was created while the module was on stays in the database, in the same place, untouched.

Re-enabling. Re-flipping the switch restores the surfaces and the data. There is no migration or rebuild step.

The exact lifecycle for each module — what gets auto-created, what to check in the first 30 minutes after enabling, what stops happening if you turn it off — is documented in the per-module post-enable runbook. Every module reference page in the grid above links to its runbook at the bottom.

Today's platform admin toggle surface​

The platform admin module-enablement UI currently exposes toggles for seven of the nine optional modules. Alumni and Messaging exist in the data model and are fully functional, but their toggle is not yet wired into the platform admin enable / disable panel — to flip them today, work with engineering directly. The full set of nine surfaces and runbooks is documented here so the docs stay aligned with what is actually shipping, not just what is wired into the admin UI.

Where to start​

  • First time setting up an org? Operations and Community on day one; everything else as needed.
  • Helping an org admin decide what to turn on? Read the module hub page, then its post-enable runbook to see what setup the first 30 minutes look like.
  • Need to actually flip a switch? See Module enablement for the org admin view, and the platform admin guide for the platform-wide view.

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