Extensibility
Purpose
No standard product fits an organisation exactly. The only question is what happens when you adapt it: whether a special edition emerges that no longer tolerates updates, or whether the adaptation was provided for.
Here it is provided for — on three levels, from the smallest to the largest.
Scope
1 — Custom fields. Fields of your own can be added to customers, contacts, leads, deals, tickets, projects and tasks. They behave like the shipped ones: filterable, reportable, reachable over the API, available in automations and to the AI. What belongs in a field does not belong in a notes box.
2 — Catalogues as data. Statuses, priorities, roles and master data lists are not program constants but records. They can be renamed, extended and reordered without anybody having to ship a new version. A category preserves the meaning, so that a freely named status keeps counting correctly in reporting.
3 — Plugins. Practically every functional area is a plugin. They can be enabled, disabled, installed and uninstalled — with a choice about whether the data stays on uninstall. A plugin brings its own permissions, master data, templates and surfaces rather than writing into the core.
Interplay
Custom fields are defined under Custom fields, plugins switched in the plugin manager. Both then take effect everywhere — including over the API and for the AI.
Limits
- A new module widens nobody's authority. Its permissions are not granted to begin with; somebody
has to assign them deliberately.
- Technical keys are permanent. The field key, the status key, the brand slug — they are attached
to existing data and are not meant to be renamed. The display label can change at any time; the identity cannot.
- Deactivating is the gentle route, deleting the final one. A deactivated entry disappears from
the selection but stays readable on existing records.
- Uninstalling with data deletion is irreversible — the recycle bin does not cover it.