Module management: turning features on and off

KudosCRM covers a lot of ground, and most teams use a subset. Modules are how a workspace is narrowed to the parts you actually work in.

The effect is bigger than hiding a menu item — a disabled module is genuinely not part of your workspace.

Who this is for

Admins shaping what their team sees.

Before you start

• Admin access.
• A clear view of what your team actually uses — turning something off that people rely on is disruptive.

Disabling is not the same as hiding
A disabled module drops out of navigation and out of the permission surface. That is the point — it reduces what people have to understand. But it also means anything depending on that module stops being available, so check before switching one off rather than after.

Manage modules

1. Review the module list
   Read what is available and what is currently on. Most workspaces have things enabled that nobody has ever opened.
2. Turn off what your team does not use
   Fewer modules means less navigation and fewer concepts for new people to absorb. This is the main benefit.
3. Check for dependencies first
   Some work spans modules. Confirm nothing your team relies on runs through the module you are about to disable.
4. Layer permissions on top
   Modules decide what the workspace has; roles decide who within it can do what. They work together rather than replacing each other.
5. Re-enable when you grow into it
   Turning a module back on restores it. Starting narrow and adding later is easier than starting wide and pruning.

What you get

• Navigation that matches what your team actually does.
• Fewer concepts for new people to learn.
• A permission surface reduced to what is in use.
• The option to expand later without losing anything.

Frequently asked questions

Does disabling a module delete its data?

Disabling is about availability rather than deletion. Still, check what depends on a module before switching it off — treat it as a change with consequences, not a display toggle.

What is the difference between modules and permissions?

Modules decide what exists in the workspace at all. Roles and permissions decide who can do what with the parts that exist.

Should a new workspace start with everything on?

Usually the opposite. Starting narrow and enabling as you grow into things is much easier than presenting everyone with a product twice the size of their job.

Can I turn a module back on later?

Yes. Enablement is reversible, which is what makes starting narrow a low-risk choice.