Plugins
Overview
Practically every functional area of this system is a plugin — quotes, invoices, projects, warehousing, time tracking. This page manages them: install, enable, disable, uninstall.
This is not a side surface but the main switch for what the system can do. What is disabled here does not exist for anyone: no menu entries, no API endpoints, no background runs, no reporting. A disabled module is genuinely off, not merely hidden.
Core tasks
Survey what exists. The list shows each plugin's icon, name, trust level and status. The levels are First-party (from the vendor), Verified partner and Community — they tell you how far a package can be trusted before you install it.
Enable and disable. The change takes effect immediately and for every user.
Restrict visibility to brands and roles. On a plugin's detail page, the Visibility section decides who an active module is there for — for instance to roll it out in one brand or for one department first. Anyone outside does not see the module in the menu and reaches neither its pages nor its API nor the AI tools (MCP). The brand selection also applies in the customer portal via the customer's brand: portal users of other brands do not see the module there. Without a selection it applies to everyone, as before. In the list, a module restricted this way carries the restricted marker.
Install from the marketplace. Marketplace opens the catalogue. Paid extensions not yet purchased lead to the vendor's checkout; purchased ones can be installed directly. If no marketplace is configured, the page says so and offers the upload instead.
Upload your own package. Upload plugin accepts a .zip package. Important: an uploaded plugin is installed disabled. You then enable it deliberately. Installation runs in the background; with larger packages the result only appears after refreshing the list.
Check capabilities before a third-party module runs. A module not made by the vendor has to declare in its package what it may do: which internet addresses it wants to reach, whether it accesses the file storage, which events of other modules it listens to and which foreign permissions it grants to roles. The detail page shows the declaration next to what the module actually uses in the Capabilities section; the list of folder packages shows the declaration before installation. If a third-party module uses more than it declares, it can neither be installed nor enabled — the message names every deviation with its location. Vendor modules need no declaration.
Network access is guarded. Every module — including the vendor's own — reaches the network only through a checked exit: only http and https, no cloud metadata addresses, every redirect checked again, and for third-party modules only the declared targets. Addresses in your own network are reachable only for vendor modules and verified partners. A rejected call looks like a network outage to the module.
Designate verified partners. Whether a third-party module counts as a Verified partner is your decision — no package can certify itself. On the detail page, Mark as verified partner (after a confirmation) switches the level on, Revoke partner status switches it off. A partner is built directly into the application and may reach addresses in your own network; the interface is rebuilt in the background for this. It still has to declare its capabilities. Every change is recorded in the audit log. Vendor modules have a fixed level.
Interfaces of unverified third-party modules run isolated. A module uploaded or installed via Composer without partner status is not built into the application. If it brings its own interface, it appears in the menu under Extensions (and via Open interface on the detail page) inside an isolated frame: it sees neither your session nor other data and reaches only the module's own interface — with your permissions.
Uninstall with a choice. When uninstalling you decide whether the plugin's data is kept or removed with it. Kept data is picked up again by a later reinstall. That choice is why uninstalling is not a one-way street — but also the point at which a slip becomes final.
Starter packages and unlocking modules
Not every business needs every module. A starter package decides which modules you work with; all others stay installed but are switched off. The Starter package card at the top of this page shows the chosen package.
The packages.
| Package | Modules on |
|---|---|
| Agency | CRM, projects, time tracking, tickets, quotes, invoicing, billing, contracts, reporting, knowledge |
| Service provider | CRM, quotes, orders, invoicing, billing, contracts, time tracking, appointments, reporting |
| Trade | products, suppliers, purchasing, orders, invoicing, shipping, reporting |
| Support | tickets, knowledge, CRM, contracts, appointments, reporting |
| Everything | every installed module |
Customers, contacts, tasks, files, calendar, search and help belong to the core and are on in every package. An existing installation works with Everything — introducing the packages switches nothing off. A new installation also starts with Everything until you choose a package.
Changing the package. Change package shows the packages as tiles. Pick one and the preview lists which modules will be switched on and which off. Confirm switches in one step. Only the module switches change — all data is kept. A switched-off module is off, not deleted: switch it on again and everything is back. If a single module cannot be switched (for example because another module objects), the message names it; the others are switched anyway.
Unlocking modules. The marketplace starts with Unlock more: every installed module that is currently off. Each card states the module's benefit and its prerequisites — which other modules it works with and what still needs setting up afterwards. Activate switches the module on with one click; the chosen package stays as it is.
With sample data. If the box is ticked, unlocking also loads the module's sample data — so you see right away what it looks like. This only works when the sample company is loaded and the module contains no data of its own yet. Otherwise the box is locked and names the reason; your data is never mixed with samples.
What is still missing. A module reports by itself what it still needs to get started — invoicing, for example, the sender for invoices, the invoice numbers and the payment term; shipping a connected carrier; time tracking an hourly rate. In the list an active module then carries the label Setup: n (open steps); on its detail page the Setup section shows one tile per gap with Configure. The step is one field: sender address, next running invoice number, payment term in days or hourly rate. Where credentials are needed (shipping), the step leads to the setup page. The same question appears where it is missing: whoever wants to send an invoice before the brand has a sender gets that one field instead of an error message — and then continues straight to sending. Users who may not perform the step see that the administrator sets it up.
Fields in detail
The overview shows modules and offers actions. The only inputs are in the Visibility section of the detail page; what a module configures functionally lives on its own settings page.
| Field | Required | Values / format | What it does |
|---|---|---|---|
Brands visibleBrandIds | no | selection of brands, empty = all | The module applies only to users with a membership in one of the chosen brands. A cross-brand membership matches every brand. In the customer portal the brand of the portal access counts (at invitation the customer's brand); an access without a brand only sees unrestricted modules. |
Roles visibleRoleIds | no | selection of roles, empty = all | The module applies only to users holding one of the chosen roles. If brands and roles are chosen, one membership must satisfy both — a role from one membership and a brand from another do not count. The role selection has no effect in the customer portal — portal users have no roles. |
The restriction is a visibility gate, not a data filter. Whoever sees the module still sees exactly what their permissions per brand allow. It applies to signed-in staff and — via the customer's brand — in the customer portal (menu, pages and portal API answer there as for a disabled module). Automations and background runs only see the main enabled/disabled switch.
| Element | From | What it means |
|---|---|---|
| Module | installed modules | Name, icon and short description. |
| Version | module | Which state is installed. |
| State | module switch | On or off. |
| Item | Source | What it means |
|---|---|---|
Capabilities — declared capabilities.declared | capabilities in the package's plugin.json | Network targets (e.g. api.example.com, *.example.com), file storage, foreign events, foreign permissions. Empty means: the module may do none of this. |
Capabilities — used capabilities.used | determined from the built-in module | What the module really uses. |
Not declared capabilities.violations | comparison of both sides | Every deviation with its location. As long as a line remains, a third-party module cannot be installed or enabled. |
Trust level trustTier | vendor list or your partner approval | First-Party (vendor), Verified partner (approved by you) or Community. The claim inside the package does not count. |
| Action | What it does |
|---|---|
| Enable | Makes the module fully available: menu entries, permissions, background processing, API. |
| Disable | Hides it completely — pages, API and background processing. The data is untouched and returns on enabling. That is the difference from uninstalling. |
| Uninstall | Removes the module. You are asked whether the data should be kept or deleted. Kept means a later reinstall picks it up again. Deleted is deleted. |
A disabled module is really off. There is no half-open door: the API stops answering too, and an automation aimed at the module runs into nothing instead of quietly carrying on.
Settings & permissions
- Permission
platform.plugin.manage. Without it the manager, marketplace and detail page are
unreachable. The same permission maintains Visibility.
- Permission
platform.setup.manage. Choose and change the starter package and switch on modules
under Unlock more (with sample data). Without it, the card and the section are missing.
- Setup steps follow the permission of the step. The sender is set up by whoever may maintain brands
(platform.brand.manage, in that brand), invoice numbers and payment term by whoever maintains the settings (platform.settings.manage), the hourly rate by whoever maintains activities (time.category.manage).
- Permission
platform.plugin.trust. Only users with it grant or revoke partner status — the detour
via the general settings is blocked without it as well.
- No exception for administrators. Visibility follows brand and role, for you too. The manager
itself always stays reachable — a selection that is too narrow can be taken back here at any time.
- Plugin modules do not appear among the feature flags. They are switched on and off here, not
under System & feature flags.
- Every plugin brings its own permissions. After enabling, they appear under
Roles & permissions — not granted to begin with.
- Disabling is fail-closed. In case of doubt a surface stays hidden rather than appearing and
then failing.
FAQ & troubleshooting
An uploaded plugin does not show up. Installation runs in the background. Refresh the list; if it still does not appear, the installation failed and the message names the reason.
After enabling, the new menu entries are missing. Check your permissions: a new plugin grants nobody authority automatically. The permissions have to be assigned to a role.
A colleague does not see an active module. Check the Visibility section on the detail page: if they belong to none of the chosen brands or roles, the module is hidden for them — via the API too. Only then look at their role's permissions.
A third-party module cannot be enabled — "uses capabilities it does not declare". The package uses more than its plugin.json states under capabilities. The Capabilities section names every deviation. Only a corrected package from the vendor helps — the declaration deliberately cannot be overridden in the interface.
A module reports "network call rejected". The target is a metadata address, is not declared by a third-party module, or lies in your own network, which only vendor modules and verified partners reach. To let a vetted third-party module into your own network, mark it as a verified partner.
A module's data is missing after changing the package. It is not missing — the module is just off. Switch it on again under Unlock more and everything is as before. Changing the package never deletes data.
"With sample data" is locked. Either the sample company is not loaded, the module has no sample data, or it already contains data of its own. The reason is shown next to the box.
The marketplace is empty. Then it is not configured. The package upload route remains available.
We uninstalled with data deletion by mistake. The plugin's data is then gone. The recycle bin does not cover this — only a backup helps. Which is why the choice during uninstall deserves deliberate attention.