CRM database: where each record belongs

What does a CRM database store?

Strip the interface away and a CRM is a small relational database with four tables that matter. Every feature you use (the board, the reports, the quote, the assistant) is a view over these.

Object	What it is	What it holds
Company (account)	The organization you sell to.	Legal name, address, industry, account code, payment terms.
Contact	A named person, usually at a company.	Name, role, email, phone, consent and communication preferences.
Deal	A potential sale, attached to a company and one or more contacts.	Value, stage, close date, owner, source, product or service line.
Activity	Everything that happened, on a timeline.	Emails, calls, notes, meetings, tasks, quotes and files.

The relationships are the valuable part, not the rows. A contact list is a mailing list; a contact attached to a company, to three deals and to two years of correspondence is a customer record, and it is the only thing that answers “what is going on with this account” without a meeting. That is the whole argument for a CRM, set out at length in what a CRM is.

An account can have many contacts and deals. A deal can link products, activities, quotes, and stakeholders. Preserve relationship history when a contact changes employers: the person is the same person, and the history is why you know them.

Leads sit in front of the four: an inquiry nobody has qualified yet. In Senitix CRM, qualifying a lead creates the contact, the account and the deal in one step, so the details typed at first contact are carried into the records rather than copied across by hand.

What a spreadsheet lacks is the operating model around the rows: relationships, permissions, change history, process rules, and concurrent multi-user work. That is exactly why it is faster on day one and slower every day after.

One test tells you whether the model is holding. Pick a customer and ask how many places their email address is stored. If the answer is one, the record is doing its job. If it is four, every correction is now four corrections, and three of them will not happen. Most of the benefits of a CRM rest on that answer being one.

What if a customer does not fit the four records?

Three real-world situations do not fit the four objects neatly, and each has a conventional answer worth adopting early rather than inventing later.

• A person at two companies. A consultant, or someone who changed jobs. Keep one contact and record the relationship to each company; do not clone the person, or half the history follows the wrong copy.
• A group with subsidiaries. Model the parent and each subsidiary as separate companies and link them. Reporting by group then works; a single flattened company record cannot be unflattened later.
• Consumers with no company. A contact with no parent is fine. Forcing every individual into an invented company is how a database fills with rows named after a person.

Where do duplicate records come from?

Duplicates are rarely typed in one at a time by a rep browsing the database. Most arrive in bulk, through four doors, which is good news: fixing a door fixes every future row that would have come through it.

So the practical rule is: define what makes two records the same thing, apply it at every entry point, and only then worry about the duplicates already in there. Matching keys and one-way flows are covered in connecting a CRM to the rest of your stack.

Senitix will not close those doors for you today: nothing stops a duplicate from being saved. It can merge two lead, contact or account records into one once you have found them, and configurable matching rules are coming soon. Until they ship, the rule you agreed on and the entry points you fixed are your defense. That is a smaller gap than it sounds. A checker still needs a person to have decided what a match is, and a team that never wrote that sentence down gets a flagged pair and an argument rather than a decision. Write the rule once, tell whoever runs imports and whoever owns each connected system, and the doors stay shut whether or not anything is watching them.

How do you clean the data that is already there?

Do this before a migration, never after. Merging two records that each carry a year of email history is significantly harder than merging two nearly empty ones, and some of it cannot be undone.

1. Agree on the identity rule. Contacts match on email address. Companies match on a tax ID, such as an EIN, or on an account code, never on company name alone, which is not a stable identifier.
2. Normalize before you compare. Trim whitespace, standardize legal suffixes such as Inc. and LLC, lowercase the email addresses and put phone numbers in one format. Many apparent duplicates disappear at this step alone.
3. Separate exact from possible matches. Two records with the same email address can be merged on the rule. Two with a similar name at a similar address go to a person who knows the account.
4. Decide which record survives. Usually the older one, because more history points at it. Before each merge, look at the filled values, the owner, the relationships and who can see each record, so nothing ends up where it should not. Write the rule down so two people cleaning different letters of the alphabet do the same thing.
5. Keep the history from both. Notes, emails and files should end up on the surviving record. Losing them is worse than the duplicate was.
6. Deal with the dead rows separately. A contact with no activity for four years and no consent to be contacted is not a cleaning problem, it is a retention decision.

Every step above is cheap for one reason: nothing is attached to the records yet. Once a row carries activity, a merge stops being a data question and becomes a set of judgments: who owns the surviving record, which of two deals was the real one, which thread belongs to which contact, and what happens to a quote that names the record you are retiring. That is why data preparation sits early in a CRM implementation, before anything is connected, rather than in the month after go-live.

Who should see which records?

Access design gets postponed because it feels political, and then it is set by whatever the software did by default. Two questions settle most of it.

First, what is the default: can everyone see every account, or only their own? Open by default suits a small team where visibility is the point and secrecy would be strange. Restricted by default suits a business where regions or entities are genuinely separate, or where the customer list is the asset. Neither is more professional than the other; what matters is that it was chosen rather than inherited.

Second, who may do the irreversible things: delete a record, export the whole database, change the stage definitions everyone reports on. Those three deserve a shorter list of people than “can view”, and the list should be written down somewhere a new manager will find it. A bulk export is worth particular thought, because it is the one action that turns your CRM into a file on somebody’s laptop.

Whichever default you land on, design the rest of it from the job rather than from the org chart. Seniority is a poor guide to what someone needs: a rep covering one region needs every record in it and nothing outside it, while a controller may need the value of every deal and none of the correspondence attached to them. Write one line per role saying what that person has to be able to do on a Tuesday morning, then grant that. It produces a model you can explain, which is what matters the first time somebody asks for an exception. Revisit it when people move, because access granted for a project that ended is how a designed model turns back into everyone seeing everything.

The levers are the same in most systems: apply role, ownership, team, field, and export rights based on need. In Senitix CRM, access is set by role, department and record ownership, and field permissions keep a sensitive value such as margin visible only to the roles that need it. A record can also be shared by hand or restricted, and an access explorer shows why a given person can see it. Rule-based sharing is coming soon.

How long should a CRM keep customer data?

A CRM holds personal data (names, roles, email addresses, correspondence), and privacy law increasingly expects you to know why you hold each category and for how long. California’s CCPA, as amended by the CPRA, asks a covered business to tell people at collection how long it intends to keep each category of personal information (Cal. Civ. Code § 1798.100); Article 13 of the GDPR asks much the same for people in the EU, and several other state privacy laws add purpose and data-minimization duties of their own. Which laws apply to you is a legal question, but the operational half is straightforward and it is yours to answer.

• Separate the categories. A contact you have a live contract with, a prospect who never replied, and a person who asked not to be contacted are three different retention cases.
• Record why you hold it. The purpose you gave when you collected it. For people in the EU, add the GDPR lawful basis, such as contract, legal obligation, legitimate interest or consent. This is the field that makes an access request answerable in an afternoon rather than a week.
• Set a review date, not a delete date. Automatic deletion of a record with an open contract attached causes its own incident. Review, then delete.
• Remember the copies. Exports, backups and the spreadsheet somebody made last March are part of your retention position whether or not anyone counts them.

Our side of it is on the record. Senitix CRM is hosted in the European Union, with no US hosting region today; providers and locations are on the subprocessors page. Our data processing agreement and data retention policy are published, so you can read both before you talk to anyone. Inside the product, a deleted record goes to a recycle bin and can be restored until its retention window closes, so a deletion is final only after that.

Your own half of it fits on one page. List the categories of person whose data you hold, and against each write the reason, the clock and the action: what starts the countdown, how long it runs, and what happens at the end, whether that is deletion, anonymization or a review by a named role. Retention follows purpose, contract, and law, so the end of the clock means deletion or true anonymization rather than indefinite storage. A lawyer can tell you whether those durations are defensible. Nobody but you can tell them what your CRM actually contains, which is why that page has to exist before anyone asks for it.

The bullets above stop at exports and backups, and the systems you sync to are copies as well. A record you delete here is not deleted in the tool you pushed it to, so a retention decision has to travel to each of them. It is one more reason to know exactly what every CRM integration sends where.

A short vocabulary

Object

A type of record: company, contact, deal, activity. The tables the whole system is built from.

Field

One piece of information on a record. Every field has a cost: someone fills it in, forever.

Relationship

The link between two records. The part that turns a list into a customer history.

Unique key

The value that identifies a record: an email address, a tax ID, an account code. Never a company name.

Merge

Combining two records into one, keeping the history from both. Cheap early, expensive later.

Data quality

How much of the database you would be willing to act on without checking it first.

Retention

How long you keep each category of data, and the reason you keep it. A documented answer, not a habit.

Access model

Who can see and change which records by default, and who may do the irreversible things.

A word this list does not define is either not needed here or particular to your own company, and the second kind belongs in the data dictionary rather than in somebody’s memory. The wider vocabulary of pipelines, stages and lifecycle sits with the definition of a CRM.

How do you keep a CRM database clean?

Cleaning campaigns do not last; small routines do. Once a quarter, look at four numbers: how many contacts have no activity in a year, how many companies have no owner, how many deals are past their close date and still open, and how many records were created by an integration in the last ninety days. Each one points at a door that needs adjusting rather than a batch of rows that needs fixing. A fuller quality report adds the rest: track critical-field completeness, invalid contact formats, possible duplicates and merge time, ownerless records, relationship completeness, stale records, integration failures, and manual corrections.

The stale-deal number is the one to watch first, because it is the number that quietly ruins forecasting: the mechanics of that are in the sales pipeline, and the wider design question of which fields should exist at all is in designing a CRM people keep updating. The habits that stop those numbers creeping back, from a dated next step on every open deal to a named owner for the system, are in CRM best practices.

In Senitix CRM, companies, contacts, deals and activity sit on one customer record, so the history stays attached to the thing it belongs to rather than to whoever happened to send the email; what each plan includes is on plans and pricing.

A backup is not the same as an export. Your recovery point objective (RPO), your recovery time objective (RTO) and the restoration of relationships, files and history each need separate evidence from whoever holds the backup. Senitix backs up its databases every day and every month to a locked vault with a copy in a second region; the copy you control is your own export, and every plan, Free included, exports records as CSV or Excel files and can schedule a full data export.

What goes in a CRM data dictionary?

A data dictionary is one row per field. For each field, record its name, definition, type, example, required status, owner, source, reporting use, sensitivity, and retention. Remove near-duplicate fields that represent the same concept.

Treat it as a working document, not an audit exercise. The definition column is the one that earns its keep: two people reporting different numbers for the same field name are almost always two people reading that name differently, and one written sentence ends it. The source column is the other, because knowing whether a value is typed by a rep, imported once or written by another system tells you who to talk to when it is wrong. Update the row in the same change that touches the field, and keep it where the people filling those fields can read it. Whether a field deserves to exist at all is a question for CRM strategy; the dictionary records what was decided.