The product is assembled from a small core and add-ons. The core is what everybody needs: the client base, the timeline, data quality, import and export, custom fields, management and the screens. Everything else connects by choice: sales, money, marketing, communications, service. This way you do not pay attention for what you do not use, and the interface stays understandable.
The core and the add-ons
The core is fully workable on its own: you can keep the client base and the timeline, clean the repeats, upload and export data, create your own fields and objects — all without a single add-on. An add-on brings its contour: its screens, its fields, its management capabilities. The arrangement is deliberately simple: either the add-on is on and works entirely, or it is off and stays out of the way.
The add-on list
In total the product ships twenty-two add-ons — four main contours, sixteen communications and service contours, one shared automation contour and one general analytics contour.
- Deals — pipelines, stages, the transition log, forecast, plans, approvals, renewals. See Deals & Pipeline.
- Money — the catalogue, prices and discounts, quotes, orders, invoices, payments, contracts, subscriptions, receivables. See Money: Quotes, Invoices, Payments & Contracts.
- Leads — request intake, routing, scoring, reaction deadlines, touch sequences. See Leads.
- Marketing — mailings, audiences, consents, attribution, surveys, coupons, events. See Marketing.
The communications contours are eight independent add-ons: Inbox (the shared inbox and the one conversation model), Mail (mailboxes, parsing rules, drafts and scheduled sending), Calls (the log and the junction with the telephony service), Messengers (correspondence over external channels), Widget and chats (the site chat, auto-replies), Calendar (meetings and booking), Notifications and Privacy (data hiding and the access log). All of them are described in the Communications section.
The service contours are eight as well: Service (tickets), Deadlines (work calendars and deadline rules), Knowledge base, Portal (the client’s own entrance), Surveys, Asset records (equipment, outages, changes), Service contracts and Partners. All of them are described in the Service: Tickets, SLA, Knowledge & Portal section.
Separately stand Automation — the shared contour for “if an event happened, do an action” scenarios, available to several other add-ons — and Analytics — the general analytical layer: reports as data, dashboards and scheduled deliveries that compose over all the records you keep.
What switching on means
A switched-on add-on adds its screens to the menu, its fields to the cards and its management capabilities. A switched-off one adds nothing: its screens are gone and its management commands do not answer. The core keeps working as usual, and the switched-off add-on’s data stays in place — it is simply not shown.
This has an important consequence: while the add-on is off, it cannot be touched by accident. If you kept a saved link to its screen, you get a clear explanation that the contour is switched off, not an error.
The add-ons catalogue
Add-on management lives in the Addons section and is available to the administrator only. Every add-on is shown as a card: name, description, version, state and what it depends on. There are four states:
- Available — shipped with the product, but not installed.
- Active — installed and working.
- Disabled — installed, the data kept, the capabilities off.
- Marked for removal — the data will be exported and the service tables deleted on the next restart.
Add-ons have dependencies — and that is not whimsy but honesty. Messengers rest on Inbox and Marketing, for example, and the Portal on Service and the Knowledge base. The product will not let you switch off what a working add-on rests on: it refuses and names exactly who is in the way. And the other way round: on installation the needed dependencies switch on first. Every add-on’s card says plainly what it gives, what it deliberately does not do and what it depends on.
Switching off with the data kept
Switching off is a soft measure. The add-on stops being shown and working, but all its data stays untouched: not one row is deleted. This is convenient when a contour is not needed always: you switched Marketing on for the campaign, then switched it off so it does not get in the way. Switch it back on — everything is where it was.
Removal with export
Removal is a more serious measure, so it is arranged carefully. Before removal all the add-on’s data is exported into a file and verified: first the export, then the removal. If the export did not work out (there was not enough space, for example), the removal is cancelled and the data stays in place — the product will not sacrifice your records for a formality. If you later decide to bring the add-on back, the data can be restored from the saved export — that is a separate choice at installation.
Fresh install and upgrade
On a fresh installation only the core is available, and all the add-ons are offered in the catalogue. This means you assemble the product for yourself from day one instead of dismantling a ready combine. When upgrading an old version, nothing is lost: everything that already worked stays on, and an add-on that arrived with the update comes as “available” — it never switches itself on. So an update cannot unexpectedly change your work.
Changes apply on restart
Installing, switching off and removing add-ons take effect after the product restarts. This is a decision in favor of reliability: changing the contour composition on the fly means risking half the state, while calmly applying the changes at startup means a predictable result. The interface always shows that a change is waiting for a restart, and until then the application works as before. Until the change applies, nothing happens to the data.
Each add-on upgrades separately
Every add-on has its own history of data-structure changes, applied separately and step by step, each step entirely. If a step fails for some reason, it rolls back completely (no “half-done” changes), the add-on does not start, and the reason goes into the log. The next start retries. This way an update cannot spoil the base partially: either the step passed, or nothing changed.
How the agent sees it
The reference the agent uses shows only what really exists: the core’s resources and the active add-ons’. This matters so the agent does not try to do what your build lacks and does not promise the capabilities of a switched-off contour. Switch the add-on on and restart — the capabilities appear in the reference too; switch it off — they disappear. No confusion of “why does the agent offer what does not exist” arises.
Next → Screens & Workspaces