Separate the Person, Company and Relationship
A consultant can represent more than one business, and a director can move between companies. A custom CRM should describe those relationships without forcing the person into a single company field or duplicating every personal detail for every engagement.
Use a contact record for the person, a company record for the business and a relationship record for the person's role at that business. Model participation in a particular deal separately, because a person's general company relationship does not describe every sales transaction.
This is a proposed operating model for a hypothetical CRM. It does not require one globally shared contact directory across unrelated SaaS customers. Tenant ownership and privacy boundaries must be decided before implementing shared identity records.
Define Stable IDs and Useful Attributes
Give contacts and companies stable internal IDs. Treat names, emails, phone numbers and domains as attributes that can change. A person may use different work emails, an address may be shared, and a company's domain may be absent or shared with another business.
| Entity | Stable identifier | Useful attributes |
|---|---|---|
| Contact | contact_id | Names, contact methods and provenance |
| Company | company_id | Name, identifiers, domains and company status |
| Contact-company relationship | relationship_id | Contact, company, business role, dates and status |
| Deal | deal_id | Commercial scope, stage and owner |
| Deal participation | participation_id | Deal, contact, represented company and deal role |
Choose uniqueness rules appropriate to the actual business. If registration numbers are used, include jurisdiction and identifier type and decide how missing or disputed values are handled. An email-only identity key can force an incorrect merge or prevent a valid second contact.
A relationship may have several roles or change over time. Either model role assignments separately or define a deliberate history/version rule. A simple unique contact-plus-company pair can be useful for one current relationship but may be inadequate for multiple engagements or historical periods.
Keep Business Roles Separate From Access Permissions
A CRM label such as Consultant, Director or Decision Maker describes a business relationship. It does not automatically grant login rights, administrative access or permission to view financial records.
An authenticated SaaS user may correspond to a contact, but that link must be explicit and verified. Maintain server-owned membership and permission records for application access. Do not grant a user company access merely because a sales representative changed the contact's CRM authority score.
OWASP recommends least privilege and authorization on every request. Apply that to contact detail, relationship history, company records, deals, search and exports. OWASP authorization guidance
PostgreSQL RLS can filter rows for ordinary roles when policies and grants are correctly configured. It has owner and privileged-role exceptions, so inspect the actual execution context and test the service's paths. PostgreSQL row security RLS does not automatically create an audit trail of relationship edits.
If two SaaS tenants know the same consultant, one tenant must not learn the other's companies, notes or deals from a shared contact record. A proposed default is tenant-owned CRM contacts with deduplication inside that tenant. A cross-tenant identity service requires a separate, explicit sharing design.
Use Deduplication as a Controlled Workflow
Normalize contact methods for comparison, then identify duplicate candidates using stable IDs, verified external IDs and agreed combinations of attributes. Preserve the original values and their source. A match suggestion is different from proof that two records represent the same person.
HubSpot documents contact email and company-domain deduplication in specific workflows, and supports record IDs or custom unique properties for imports. It also explicitly excludes companies created through its API from automatic company-domain deduplication. Do not generalize its behavior into a universal custom-CRM rule. HubSpot deduplication behavior
For custom imports, define how the system handles an existing internal ID, a known email, a changed email, a shared address, no email and conflicting identifiers. Return a clear review state for ambiguous matches rather than silently merging personal data.
A merge needs an approved survivor record, field-conflict decisions, relationship and deal reassignment, duplicate-ID redirects and a record of who approved it. Test that imports can be retried without creating duplicate relationships or applying the same merge twice.
Scope duplicate discovery to the authorized tenant. A response such as “this email already belongs to a contact in another organisation” can leak information even when the original record is not returned.
Model Deal Participation Explicitly
A deal should reference its intended company or companies under an explicit commercial model. Each participation record should identify the contact, the represented company and their role in that deal.
A consultant who advises AlphaTech generally may represent Beta Solutions in a specific transaction. The deal participation must not silently inherit the wrong company from the contact's first or primary company.
Decide how historical participation is preserved after a relationship ends. Ending a company relationship can stop new assignments without deleting the contact's role in an earlier deal. Application permission to read that deal remains governed by separate authorization records.
If the participation references a relationship, verify that it is in the same tenant and represented company. If historic participation is permitted after an engagement ends, state that rule explicitly instead of requiring every historic deal to reference a currently active relationship.
Filled Hypothetical Relationship Specification
Suppose Thabo is a consultant with three business relationships inside one customer's CRM. The dates and IDs below are invented fixtures.
| Record | Proposed contents | Operating rule |
|---|---|---|
| Contact C-1001 | Thabo, one verified contact method | Stable ID survives a changed email |
| Company CO-2001 | TechNova | Independent company record |
| Relationship R-11 | C-1001 advises CO-2001 from 2022-01-15 | Business role does not grant login access |
| Company CO-2002 | GreenFields | Separate notes and deals |
| Relationship R-12 | C-1001 advises CO-2002 from 2023-03-01 | Role changes preserve relevant history |
| Company CO-2003 | BuildRight | Independent company record |
| Relationship R-13 | Project Manager, 2023-06-01 to 2023-12-31 | Ended engagement; not current in 2026 |
| Deal D-3001 | Historic BuildRight project | Represented company is CO-2003 |
| Participation P-31 | C-1001, CO-2003, Lead Project Manager | Preserves historic participation |
At the October 2026 review date, the BuildRight engagement with a December 2023 end date cannot be presented as a current active assignment without an explicit renewal. Keep the historical relationship and participation, while using current dates and status rules for new assignments.
This example does not assert that Thabo can sign into the CRM or read any company's internal financial data. A separate user membership and permission decision would be required.
Practical Operating Worksheet
| Step | Proposed action | Evidence or recovery |
|---|---|---|
| Create contact | Allocate stable ID and tenant owner | Review ambiguous duplicate candidates |
| Add contact method | Store value, type, verification and provenance | Changed email retains the same approved identity |
| Create company | Allocate stable ID and review identifiers | Shared domain does not force a merge |
| Link person to company | Record role, dates, status and source | Correct relationship rather than duplicating person |
| Add deal participation | Bind deal, person and represented company | Reject mismatched tenant/company references |
| End relationship | Record end date and end current assignment | Preserve permitted historical participation |
| Merge contacts | Approve survivor and relationship reassignment | Keep audit evidence and reversal plan |
| Enforce access | Check authenticated membership and record scope | Business role cannot escalate application rights |
Assign an owner to approve each ambiguous match and merge. A fully automatic “same email means same person” policy may work for a narrow validated workflow, but it must be a deliberate product rule with known exceptions rather than an assumed fact.
Acceptance Tests for the Model
| Test | Expected result |
|---|---|
| One contact linked to two companies | Two distinct relationships without duplicate personal record inside the tenant |
| Contact changes work email | Stable ID and relationships preserved |
| Two people use a shared address | Review path prevents incorrect automatic merge |
| Company changes domain or has several domains | Stable company identity preserved |
| API/import retries same source record | No duplicate contact, relationship or participation |
| Historical engagement ends | New assignments follow date/status policy; past deal role remains |
| Deal participation selects another represented company | Explicit allowed reference or validation failure |
| Tenant B requests tenant A contact relationships | No A names, counts, notes or deal metadata |
| CRM authority score is raised | Application permissions remain governed by separate membership |
| Approved merge is applied | Relationships and deals point to approved survivor without lost history |
Use positive controls as well as denied cases. A permitted tenant user should see the intended relationship history and deal role. A filter that hides every relationship is not a useful or complete implementation.
Recover From Modeling and Import Errors
If an incorrect relationship was created, correct its role, dates or represented company with recorded provenance. Do not merge two people simply to remove an unwanted company link.
If a duplicate contact is confirmed, inspect both records' notes, relationships, contact methods and participation before merging. Resolve conflicts explicitly, preserve approved history and test that repeated import does not recreate the duplicate.
If access is excessive, inspect the separate user-membership policy and all search/export paths. Changing a CRM role label alone may not repair an authorization bug. Repeat the cross-tenant fixture tests and read the corrected data through an ordinary user.
The specification is complete when the person-company model, deduplication choices, historical participation and application authorization rules can each be explained and tested independently.
Frequently asked questions
Should contacts have multiple email addresses in the CRM?
Use a stable internal contact ID and store one or more contact methods with provenance. A preferred email can support a particular matching policy, but changed or shared addresses should not redefine the person's identity automatically.
How to handle contacts who change companies?
Update the contact-company relationship table by ending the previous relationship and creating a new one for the current company, preserving historical data.
Can a company have multiple domain names?
Yes. Store the domains as company attributes and use a stable company ID. Decide how domains contribute to duplicate matching; a primary-domain preference is a product rule, not universal identity proof.
How to ensure data security when contacts represent multiple companies?
Use verified application membership and record permissions, with tested database policies where appropriate. A contact's business relationship or authority score must not automatically become a SaaS access grant.
If your business needs a tailored CRM that accurately models complex contact and company relationships, or if you need help implementing these best practices, get in touch with our CRM development services. We also offer broader SaaS development solutions and guides on integrating AI automation in your CRM workflows (AI CRM integration guide) to enhance your sales and marketing efforts. Learn more about key marketing dashboard metrics and AI CRM integration in our glossary.