Glossary
What is crm database?
A CRM database is the stored set of records behind a CRM: the companies, the people, the deals, and every interaction the business has had with them, kept in one place and linked together.
Four object types carry almost everything
Companies are the organisations. People are the humans, and they belong to a company today and possibly a different one next year, which is why the person record has to survive the job change.
Deals are potential or actual money, attached to a company. Activities are the things that happened: emails, meetings, calls, notes. Almost every other object in a CRM is one of these four with a different label on it.
The relationships between them matter more than the fields inside them. A CRM where a person can only belong to one company cannot model a board member, a former client, or a consultant who works across three accounts, and those are exactly the relationships worth having.
It decays whether or not anyone touches it
People change jobs. Companies get acquired, rename, and move domains. Email addresses stop working. A B2B contact database loses a meaningful share of its accuracy every year through nothing more than the world carrying on.
That decay is invisible in the interface. A record with an email that bounced last month looks identical to a live one until someone tries to use it, which is usually the moment it matters.
The defence is capture rather than cleanup. A database fed automatically from real email and calendar traffic corrects itself as a side effect of the work. A database maintained by asking people to update fields does not.
Duplicates are the other quiet failure
Two records for one company means half the history on each. Nobody notices, because whichever record you open looks reasonable. The cost appears at exactly the wrong moment: an account manager calls a client who spoke to someone else last week and has no idea.
Deduplication needs to run continuously on entry, not as an annual project. By the time a merge is a project, the history is already split across hundreds of records.
How crm database works in a CRM
- One record per real thing. A single company record, whatever spelling of the name arrived. Merge on entry, not once a year.
- Fields with an owner and a use. Every custom field should have a report or a workflow that reads it. Fields nobody reads still have to be filled in by somebody.
- History that is not attached to a seat. When someone leaves, the client history must stay. If it lived in their mailbox, it leaves with them.
- A freshness signal. Last verified, last contacted, last automatic update. Without it you cannot tell a live record from a fossil.
How we do it in Lumenbase
Lumenbase builds its records from captured email, meetings, and LinkedIn activity, so a contact who changes employer shows the change from their real traffic instead of waiting for someone to notice. Duplicate detection runs at entry, and merges keep both timelines rather than choosing one.