Module access control
Module access decides which optional modules a member can use. Projects and Docs are available to every member of the workspace. CRM, Support, and Automation are granted separately, so you can give each person only the modules their work needs.
Who has access to what
Member | Projects | Docs | CRM | Support | Automation |
|---|---|---|---|---|---|
Owner or Admin | Yes | Yes | Yes | Yes | Yes |
Member or Viewer | Yes | Yes | If granted | If granted | If granted |
Owners and admins always have every module. For everyone else, CRM, Support, and Automation appear only after access is granted.
Grant module access
You need permission to manage module access (admins and owners have it).
Open Settings → Module access.
Grant CRM, Support, or Automation to a team — everyone in that team gets the module — or to an individual member as a direct exception.
To see or change one person's access, open the member from Settings → Members. Their module access is listed with any teams it comes from.
Access that comes from a team follows team membership: remove the person from the team to remove that access.
Module access and roles work together
Module access controls which modules a member can open. Their workspace role controls what they can do inside a module — for example, a Viewer can read Docs but not edit them. Both are enforced by Helpin itself, not only hidden in the interface.
API references (external spaces)
External-capable spaces can also host API references — documentation generated from an OpenAPI definition, with its own sync and publish steps. Members who can read and edit Docs can manage them, and publishing them publicly needs the same permission as publishing articles. See Help Center for how public rendering works.
Was this article helpful?