Custom CRM modules without a migration project
Properties, Shipments, Contracts, Inspections — the objects your industry has and standard CRMs do not. How to add them yourself, and when a custom field is the better answer.
Every industry has objects the standard CRM object model does not contain, and the workaround is always the same: a custom field with a comma-separated list in it, or a spreadsheet nobody admits to.
The test: does it have a life of its own?
The distinction between a field and a module is simpler than it looks.
A field describes a deal. Expected close date, discount percentage, lead source. It has no existence apart from the record it sits on.
A module exists whether or not a particular deal does. A property exists before anyone enquires about it and after the sale closes. A shipment is referenced by a deal, a support ticket and an invoice. A contract outlives the salesperson who signed it.
If you find yourself maintaining a list somewhere so that people can pick from it consistently, you have found a module.
What this looks like in practice
Real estate
Properties, with configuration, floor, facing, carpet area, price per square foot and possession date. A deal references a property rather than copying its details, so a price revision updates everywhere at once instead of in forty deals individually.
Logistics
Shipments, with origin, destination, weight, mode and status. Referenced by the deal that sold the job, the invoice that bills it and the support conversation when it is late.
Facilities and services
Contracts and Inspections. A contract runs for a year and generates scheduled inspections. Neither is a deal; both relate to one.
Diagnostics and healthcare
Samples and Reports, which have a lifecycle entirely their own and a compliance trail that a notes field cannot carry.
Why most CRMs make this hard
Not because the engineering is difficult. Because their data model was fixed years ago and custom objects were added later as a layer on top — which is why they are often restricted to higher tiers, limited in number, and slow to report on.
In TicAte CRM, modules are not a bolt-on. Fields, sections and whole objects are added in a minute, by you, without a release and without a quotation. And because every client has a database schema of their own, your Properties table is genuinely yours — not rows in a shared table with a tenant column.
Three mistakes worth avoiding
- Building a module for something you do five times a year. A custom field and a note are fine. Not everything deserves an object.
- Copying attributes instead of referencing. If a deal holds its own copy of the property price, those copies will diverge, and you will not find out until someone quotes the old number.
- Modelling your org chart as modules. Teams and roles already exist. Use them.
Start from last Tuesday
The practical way in is not to design a schema. It is to take one real transaction from last week, follow it from first enquiry to paid invoice, and write down every place somebody opened a spreadsheet. Those are your modules, in priority order, with no architecture discussion required.
That is also how we decide what to build, which is not a coincidence.
