CRM and the Rest of the Platform
The CRM capabilities are not a separate product bolted on. They operate over the same datastores as everything else, which is where most of the value is.
Where to find it
Architect Panel → Commercial:
- Boards & Pipeline — pipelines
- Campaign Manager — campaigns
Architect Panel → Data:
- Datastores — the shared records
- Activity Stream — the timeline on each
Architect Panel → ERP - Setup:
- Documents — quotations and orders raised against the same records
One record, many views
An organisation in your CRM can be the same record that ERP raises invoices against, that case management logs complaints on, and that messaging sends letters to. There is no synchronisation, because there is no second copy.
That is the practical argument for doing CRM here rather than alongside: the integration problem that consumes most CRM projects does not exist.
The timeline is shared
Every record carries an activity stream. A sales call, a support case update, an invoice and a marketing e-mail can all appear on one organisation's timeline in order.
That is the view a salesperson actually wants before a meeting, and it is normally impossible without an integration project.
Pipelines are not only for sales
A board in pipeline mode works over any datastore with a stage field. Recruitment, grant applications, onboarding, planning consents, tender submissions — anything that moves through stages towards a won or lost outcome fits.
Do not assume the feature is only useful if you sell things.
Campaigns reach any datastore
A segment names a datastore, criteria, and which fields hold the contact details. So a campaign can go to customers, members, tenants, alumni or applicants — whatever you have modelled.
Permissions apply as normal
Row-level access, field security and classification all work on CRM records like any other. A salesperson can be restricted to their own accounts, and a commercially sensitive field hidden from everybody but the deal owner, without any CRM-specific mechanism.
So does the audit trail
Every change to a contact or opportunity is recorded with before-and-after values and a tamper-evident chain. That matters more than it sounds in a sales context — disputes about who changed a close date or a value are common, and here they are answerable.
Build the model once
The temptation, when a second team needs something similar, is to build them their own datastore. Resist it for the same reason as always: two models of the same thing diverge, and reporting has to reconcile them.
Worked example
An organisation's Organisations datastore serves sales, support and finance. A pipeline runs over Opportunities, complaints are cases against the same organisation, and ERP invoices reference it. Before a renewal meeting, the account manager reads one timeline containing the last campaign, two support cases and the outstanding invoice.
Recommendations
- Use one record per real-world thing, across every function.
- Consider pipeline mode for any staged process, not just sales.
- Apply the normal permission layers — there is nothing CRM-specific to learn.
- Never build a second contact datastore for a second team.