Enable or disable modules

Every feature in GCM is a module — Members, Attendance, Giving, Calendar, Workflows, all of it. The Modules page (sidebar → Modules) lets an admin turn individual modules on or off for the whole organization. Disabling a module hides it from the sidebar, blocks its routes, and prevents notifications from referencing it — clean removal, not a soft hide.

Why disable a module

Most orgs disable a handful of modules to keep the sidebar relevant:

• A church without a building doesn't need Map or Org Structure.
• A small congregation that doesn't run weekday programs can drop Schools and Ministries.
• An org that handles giving entirely off-platform (e.g. via a separate accounting system) can hide Giving to avoid confusion.
• A staff-only deployment can disable Visitor Form and Website Builder.

Disabling isn't deleting — your data stays put. Re-enable the module any time and it picks up exactly where you left off.

Open the Modules page

Click Modules in the sidebar. The page shows every module available on your plan, grouped by category:

• Core — Dashboard, Members, Settings.
• Engagement — Attendance, Calendar, Groups, Ministries, Bulk Actions.
• Communication — Messaging, Conversations, Workflows.
• Analytics — Reports, Demographics, Data Logs.
• Education — Schools.
• Administration — Users & Roles, Billing, Org Structure, Custom Fields, Channels, PWA App, Accessibility.

Each row shows the module name. A small lock icon appears next to a module that's locked on (because another enabled module depends on it). Admins see a toggle switch on the right; non-admins see read-only "On" / "Off".

Toggling a module

Click the switch. The change is immediate — no Save button.

When you turn a module off:

1. The dispatch updates org_modules (one row per (org, module)).
2. The bootstrap provider re-fetches your enabled-modules list.
3. The sidebar removes the link without a page reload.
4. The route guard now returns a 404 if anyone tries to deep-link the disabled module.

When you turn a module on:

1. Same dispatch, opposite direction.
2. The link reappears in the sidebar.
3. Any data previously created (members, donations, events) is still there — disable wasn't a delete.

Module dependencies

Some modules depend on others. Examples:

• Connection Network depends on Members (without member records, there's nothing to connect).
• Check-In depends on Attendance (it's a faster way to record attendance).
• New Members depends on Members.
• Demographics depends on Members.

The page reads these dependencies from module_dependencies and prevents disabling a module that something else needs. The disabled module's switch is greyed out with a small lock icon next to its name. Hover the lock and the tooltip explains which other module is keeping it on.

To disable a locked module, first disable the modules that depend on it. The lock clears once the last dependent is off.

TIP

If you're trying to slim the sidebar drastically, work top-down. Turn off the leaf modules first (the ones nothing else depends on), then walk back up the tree.

If you try to disable a module that has enabled dependents, a destructive toast tells you exactly which modules are blocking the change.

Plan vs module

Your plan (Starter, Growth, Network, Unlimited) sets the available module list — Growth includes everything Starter has plus more, Network adds custom domains, Unlimited removes the recipient cap on bulk sends. The Modules page only shows modules your plan includes; modules from higher plans don't appear here at all.

If you want a module that's not in your plan, upgrade your billing — the new modules appear here right after the plan change is processed.

The card header reminds you which plan you're on: "Your growth plan includes these modules."

What disabling hides

Disabling a module hides:

• The sidebar link.
• The route (deep links return 404 via the ModuleGuard).
• Any sidebar groups that contain only this module.
• Workflow-builder nodes that reference this module (greyed out with "module disabled").
• Notification templates targeting this module (they pause until re-enabled).

It does not hide:

• Historical data — every donation, attendance record, and member stays in the database.
• Audit logs that mention the disabled module.
• Reports that previously included data from this module — re-enable and the report still works.

Platform admin module

The Platform Admin module is special: it's only visible to users with is_platform_admin = true in their JWT, and the Modules page hides it from the list (you can't disable platform admin from the UI even as an admin). This is by design — platform admins manage the whole multi-tenant system, including impersonating tenants for support.

What's saved where

Two tables back this page:

• modules — the platform catalog. One row per module ID with name, category, plan, and dependencies.
• org_modules — per-org overrides. One row per (organization_id, module_id, is_enabled). Missing rows default to "enabled if your plan includes it".

The useModules hook reads both at app startup, computes the effective enabled set, and broadcasts changes to the sidebar and route guards.

Common pitfalls

"I disabled Calendar and now event reminders aren't sending." Correct — disabling Calendar disables event reminders too. They share the underlying events table but the reminder dispatch is gated by the Calendar module being enabled.

"The sidebar still shows the disabled module after I refresh." Hard-reload (Cmd+Shift+R). The frontend caches the enabled-modules list for the session; a full refresh re-fetches it.

"I can't disable Members." Members is core — almost everything depends on it. The lock icon next to its switch tells you so. To disable Members, you'd need to disable virtually everything else first, which is why nobody does this.

"My role lost access to a module after enabling it." Module enable and role permissions are separate. Enabling a module exposes it; whether your role can read or write within it is the Users & Roles story.

Next steps

• Settings overview — for tabs that live under Settings rather than as their own page.
• Users & Roles — control who within your org can use the enabled modules.
• Channels — Channels is itself a module; enable it here first.