Restrict who can see each module

By default, every enabled module is visible to every member of your org. That's the right answer most of the time. When it isn't — when only your finance team should see Accounting, or only managers should see Workforce reports — use Module Permissions to lock a module to specific users, worker titles, or departments without disabling the module entirely.

Where to find it:
Settings → Modules → click the gear icon on any enabled module → "Module Permissions" tray slides in.

Two layers of control:

1. Module visibility — should this module appear at all?
• Everyone (default) — every member of your org sees the module in nav and can open it
• Restricted — pick exactly who. You can mix three filter types:
• Specific users (uid) — useful for one-off exceptions
• Worker titles — e.g. "Manager," "Server," "Driver" (sourced from `workforce_settings.main.defaultRoles`)
• Departments — e.g. "Finance," "Operations," "HR"
Anyone matching any of the three lists gets access; everyone else sees a friendly "This module isn't available to you" empty state if they navigate to one of its URLs directly.

2. Capabilities — fine-grained controls inside the module:
• Modules that declare capabilities (e.g. "Export to CSV," "Issue refunds," "Mark resolved") get a per-capability ACL widget in the same tray
• Each capability uses the same Everyone / Restricted picker — so you can let everyone use the module but only managers issue refunds
• Capabilities default to Everyone — turn them down individually as needed

Important always-on access:
• Owners and admins always pass module + capability ACLs. They have to be able to configure the rules.
• If no ACL doc exists for a module, it defaults to Everyone — this is back-compat for orgs created before Module Permissions existed.

How worker-title matching works:
The ACL stores free-text titles + free-text departments. Each viewer's match is computed by reading their `Worker` record in this org (if they have one) and checking whether `Worker.title` or `Worker.department` appears in the ACL's allowed lists. Orgs that haven't enabled Workforce have no worker records, so worker-title rules don't apply — fall back to per-user (uid) rules in that case.

Saving and reverting:
• "Save permissions" writes the ACL doc to `orgs/{orgId}/moduleAccess/{moduleKey}`
• "Reset to Everyone" deletes the doc — back to the default
• Changes take effect immediately on every active session — no sign-out required

Module-specific settings tab:
Some modules (Articles, Articles approval policy, Wally, Observability, etc.) carry their own dedicated settings tab. The tray's footer offers "Open full settings →" to jump straight there — useful so you don't have to close the tray and hunt for the right tab.

When to use this vs. disabling the module:
• Disable the module entirely if no one in the org should ever use it
• Use Module Permissions when most of your org doesn't need it but a subset does — Accounting + HR + Compliance are common candidates

What this is NOT:
• A row-level ACL. Restricting visibility hides the entire module's nav + pages. It doesn't filter individual records inside a module.
• A role hierarchy. There's no inheritance — every module gets its own ACL.
• A way to grant admins to a non-admin. Admin role is set on the org membership; this is module-level visibility on top of role.