Modules

A business should be able to enable the capabilities its team needs and keep optional screens out of the way. Modules control those areas of the workspace, while shared core capabilities remain available to support the connected records and workflows.

A small set of core modules, command, pipeline, conversations, contacts, intelligence, and system, stay on for every workspace, because the rest of the product assumes they exist. Everything else is optional, and what you enable is what your team sees.

What happens when you turn one off

Turning off a module is not cosmetic. Its navigation entries disappear from the sidebar, so nobody stumbles into a screen that will not work. Its admin routes show a disabled notice instead of the real page if someone bookmarks a direct link. Its API routes refuse the request outright rather than silently doing nothing. And its AI tools are marked unavailable to both the assistant and any external MCP client, so the assistant will not attempt an action your workspace has not turned on.

The Integrations screen is the one deliberate exception: it can always re-enable a module, because gating Integrations itself would strand an operator with no way back once something got turned off by mistake.

Where to change it

Open Integrations in your workspace. Each module's card shows whether it is currently on, which AI tools it owns, and a documentation link that the build itself verifies is live, so a module can never ship pointing at a dead guide. See Workspace for the rest of what lives on that screen.

Adding one that does not exist yet

A third party registers a new module as a manifest under extensions/ in the source, rather than editing the core application directly. That keeps your changes separate from the parts of the product everyone shares. The full contract for what a manifest needs is in the repository's extending guide, and CI itself enforces one rule you cannot skip: a module that ships without a docs URL resolving to a real, live guide fails the build.