Modules and features
Switching the helpdesk, the knowledge base, time, the CRM and the features in each on and off for a workspace, what starts off, and what somebody sees when something is off.
A workspace has all five modules, and an administrator chooses which of them, and which features in each, the team uses. A team that only runs a helpdesk need not be shown a CRM, and one that wants no public forms or AI agents can say so in one place: Administration, Modules and features.
Switching things on and off
The page lists the modules with the features of each under them. Every one has a line saying what it is, what goes when it is off, and a Switch off or Switch on button. A change is saved as you make it and written to the audit log with your name.
Switching something off hides it and refuses it, for everybody, administrators included. It deletes nothing: the contacts, pages, activities and deals are all there again when you switch it back on. No switch is tied to a plan or a licence, and none changes what a seat is.
A feature belongs to its module: while the CRM is off, so are the sales pipeline, quotes and the rest of it. Each keeps its own switch, so switching the CRM back on brings them back as they were. The page says Waiting beside a feature that is switched on while something it needs is off.
Beside each module the page says what the workspace holds of it, such as the number of contacts or pages, so you know what goes out of sight before you switch it off.
| Module | What has a switch |
|---|---|
| Projects | Boards; sprints and the backlog; voting on tickets; the list of who has a ticket open |
| Helpdesk | The helpdesk itself; the customer portal; public request forms; help articles for customers |
| Knowledge base | The knowledge base itself; comments on a passage |
| Time | Time itself; the effort and cost report; customers and invoicing |
| CRM | The CRM itself; the sales pipeline; quotes; the sales reports; writing email to contacts; iCloud calendars |
| Programs and AI agents | The REST API; the MCP server |
What starts off
A new workspace has every module on. Four features start off, because each lets somebody or something in from outside the workspace, or keeps a credential for an account elsewhere:
- Public request forms, which let anybody on the internet send the workspace a request.
- The REST API, through which a script holding a member's token reads and changes what that member can.
- The MCP server, through which an AI application a member approves does the same.
- iCloud calendars, which keep a member's Apple ID and an app-specific password.
Switch on the ones you want. A workspace that existed before these switches did keeps everything as it was, on.
The first time
The first administrator of a new workspace, or of a new installation, is taken to this page once, straight after setting it up, to choose what the workspace uses. What starts off is listed first, with what each lets in. Continue goes on to the home page. Leaving without pressing it changes nothing: the defaults apply, and a notice on the home page and the Administration page leads back until somebody has been through it. Everything on the page can be changed later, as often as you like.
The REST API and the MCP server
The two ways in for a program are switched separately, and neither needs the other. With the REST API on and the MCP server off, your own scripts and integrations work and no AI application can connect; the other way round, an AI application connects and nothing can call the API.
Tokens and connected applications belong to both. A member can make a token while either is on, and a token is refused at the one that is off. With both off nobody can make a token and every existing one is refused; none is deleted, so nobody has to connect again when you switch one back on. See AI agents.
What has no switch
- Projects and tickets are what every other module works on, and are always on.
- What only works once it is set up is off until you set it up, on its own page under Administration: single sign-on, storage, search, receiving email, GitHub and GitLab, Google and Microsoft calendars, docs from Git, SLAs, security levels and every importer.
- What is owed to somebody else: a contact's consent, copy and erasure stay reachable for as long as the workspace holds contacts, and the workspace export always works.
When something is switched off
Its menu entries and buttons are not shown, and its pages answer with a page that says it is switched off in this workspace and to ask an administrator. An administrator sees the same page with a link here. What it holds leaves search results, and a program calling the API or MCP for it is told feature_disabled with the same sentence.
A project belongs to the module of its kind: a helpdesk project and its requests are hidden while the helpdesk is off, and a sales project and its deals while the sales pipeline is. The administrator's project list still shows them, marked hidden, and nothing else does.
An import that brings data for something that is off says so before it runs. It brings the data all the same, which stays out of sight until you switch the module on; an import never switches anything on by itself.
Mail that arrives for a module that is off, such as a request by email while the helpdesk is off, is held for review under Administration, Email, never dropped.
In the demo
The public demo workspace has everything switched on, the REST API and the MCP server included, so that all of it can be tried. What it does not offer is connecting an account of your own somewhere else: a calendar, a mailbox, a GitHub or GitLab repository, a storage bucket or a single sign-on provider. The demo's logins are published, so whatever one visitor connected would be open to everybody who tries it after them. A trial workspace of your own has all of these.