Module Gating
Control which ProBeya modules are available to your organization and understand how plan tiers, overrides, and live propagation work.
Overview
Module gating lets organization administrators decide which ProBeya modules are visible to their team, within the limits of the organization’s subscription plan. Platform administrators can grant exceptions for pilots, evaluation programs, or remediation.
Core modules — Dashboard, Actions, Settings, Notifications, Search — are always available on every plan. The remaining modules can be toggled on or off.
Plan ceilings
Each plan defines the maximum set of modules your organization can enable. You can enable any subset of these modules. Disabled modules remain installed on the platform but are hidden from your team until re-enabled.
| Module | Free | Starter | Pro | Enterprise |
|---|---|---|---|---|
| Dashboard (core) | Yes | Yes | Yes | Yes |
| Actions (core) | Yes | Yes | Yes | Yes |
| Notifications (core) | Yes | Yes | Yes | Yes |
| Search (core) | Yes | Yes | Yes | Yes |
| Settings (core) | Yes | Yes | Yes | Yes |
| KPIs | No | Yes | Yes | Yes |
| Routines / TIER boards | No | Yes | Yes | Yes |
| Problem Solving | No | Yes | Yes | Yes |
| Portfolio | No | No | Yes | Yes |
| Resource Planning | No | No | Yes | Yes |
| Capacity Planning | No | No | Yes | Yes |
| Training | No | No | Yes | Yes |
| Hoshin Kanri | No | No | Yes | Yes |
| Audits | No | No | Yes | Yes |
| Multi-Site Benchmarking | No | No | No | Yes |
| Technology Transfer | No | No | No | Yes |
| Cleanroom | No | No | No | Yes |
The authoritative source is packages/shared/src/plan-allowed-modules.ts in the ProBeya monorepo. If this table drifts from the source, the source wins.
Toggling modules (organization administrator)
Who can do this: users with the Owner or Admin role on the target organization.
- Sign in to your ProBeya tenant (
{tenant}.probeya.com). - Open Settings from the main navigation.
- Choose Modules in the settings sidebar.
- The page lists modules grouped by category. Modules above your plan ceiling are rendered disabled with an upgrade hint.
- Check or uncheck the modules you want to enable for your team.
- Click Save changes in the sticky save bar.
A toast confirms success. Every active session in your organization receives a navigation refresh within approximately 200 ms — no page reload required. Affected modules immediately appear or disappear from sidebars, bottom navigation, and dashboards.
What happens when a user tries to access a disabled module
- Via navigation: the module does not appear in the sidebar or bottom navigation.
- Via a saved deep link or bookmark: ProBeya renders a Feature disabled full-page alert with a “Contact admin” call-to-action. No data is exposed.
- Via the API: requests return a
FORBIDDENerror with messageFEATURE_DISABLED. Third-party integrations should handle this code by surfacing the same “contact admin” message.
Audit trail
Every module toggle writes an audit_events row:
- Action:
org.module_toggled - Actor: the org administrator who saved the change
- Before / after: the full module arrays (useful for compliance reporting)
- Timestamp: server-side, UTC
Super-admin overrides (see below) write org.module_override with the mandatory reason.
Super-admin overrides
Super-admin overrides bypass plan ceilings. Use them only for documented pilots, Change Control Records (CCR), or contractual exceptions. Every override requires a reason of at least 20 characters and is permanently audit-logged.
Platform administrators can:
- Grant a module above the plan ceiling (for example, lending Pro features to a Starter tenant for a two-week evaluation).
- Revoke a module the org admin enabled (for example, temporarily disabling a module during remediation).
Overrides are applied on top of the org admin’s selection: (enabled ∪ granted) − revoked, intersected with plan ∪ granted.
Live propagation
Module changes are pushed to every active client session for the affected organization through a WebSocket event. This means:
- Sidebars, bottom navigation, and dashboard cards update without a manual refresh.
- Open pages for a newly-disabled module redirect to the Feature disabled state on their next interaction.
- The audit trail is always written before the propagation event fires, so no client can observe an enabled-but-unaudited state.
Backward compatibility
Organizations created before module gating was introduced continue to have access to every module allowed by their plan. The underlying storage defaults (enabled_modules = NULL) are interpreted as “all plan-allowed modules enabled”. No action is required on existing tenants.
Frequently asked questions
Related
Was this page helpful?