Design Contact-to-Company Relationships That Change Over Time

Model changing employment with effective-dated person-company relationships that preserve interaction context, uncertain dates and contact restrictions.

10/23/20263 min read

Jo has one person ID and separate former and current affiliations, with earlier meetings preserved.

A single employer field is convenient until someone changes jobs. Overwriting it can make old meeting notes appear to belong to the new employer, while keeping the old value leaves the current record wrong. Model the person and their company relationship separately so a change does not rewrite history.

The practical design is an effective-dated affiliation record. It links a stable person ID to an organization ID for a defined role and period. This is a proposed data model, not a claim that every CRM supports the same objects or historical behavior.

Separate identity from affiliation

Keep the person record focused on the identity needed for your permitted business purpose. Put employer, role, relevant business unit and dates on the relationship. This allows the same person to have a former relationship and a current one without becoming two unrelated contacts.

Use separate fields for the date the relationship became effective and the date you learned about it. A profile checked today may describe a move that happened earlier. If the start date is not known, store that uncertainty rather than using today's date as a convenient substitute.

Define a compact relationship record

Useful fields include relationship ID, person ID, organization ID, relationship type, role description, effective start, effective end, date certainty, evidence reference and verification date. Add a current-state indicator derived from reviewed evidence, not merely the absence of an end date.

Decide how interactions link to the relationship that existed when they occurred. A meeting about the former employer should retain that context. Do not automatically transfer account notes, confidential material or project commitments to the person's new organization.

Work through a fictional job change

Person P-204 is Jo, a fictional operations professional. Relationship A-17 links Jo to fictional Mapleline Services as a planning coordinator. A confirmed business conversation later establishes that Jo has moved to fictional Sable Operations, but the exact departure date is not provided.

The team marks A-17 as former, records that the end date is unknown, and preserves the evidence explaining the status change. It creates A-29 linking P-204 to the new organization, with the new role and its own source. Earlier Mapleline meeting records remain associated with A-17.

The team does not move Mapleline's opportunity to Sable or assume that Jo can discuss the former employer's project. Contact preferences are reviewed separately and are not reset by the employment change. The example is synthetic and does not describe a real contact or executed CRM migration.

Decide how to handle uncertain overlap

Sometimes two affiliations appear current because one source is outdated or a person legitimately holds several roles. Do not close one relationship solely because another appears. Keep both as unresolved where necessary and identify the question that matters to the intended use.

A return to a former employer should normally create a new dated relationship period rather than erase the gap. An internal promotion may require a new role period within the same organization. The chosen granularity should support real decisions, not produce an elaborate employment biography without purpose.

Test the design before import

Use synthetic cases for a known job change, unknown dates, overlapping affiliations, a return and a corrected identity match. Check what the CRM does with existing interactions, company associations and unique identifiers. Product-specific import behavior and subscription limits require verification in the actual environment.

If the system cannot represent the history safely, maintain an approved relationship ledger or a limited historical reference rather than pretending a flat employer field is sufficient. Avoid duplicate personal records as an unexamined workaround.

Finally, apply retention and access rules to the relationship history. Historical usefulness does not justify keeping every personal detail indefinitely. A successful model lets a colleague answer “Which organization was relevant to this interaction?” while still seeing the current relationship and its uncertainty. It should preserve context, not create new assumptions about permission or buying authority.

Research access and CRM configuration are separate purchases. Leads Automation offers an independent US$15/month service and is not affiliated with LinkedIn. Confirm the actual plan, eligibility and terms; do not assume schema design, imports or integrations are included. Discuss the offer on WhatsApp.

Sources and scope

This is a proposed operating method, not a vendor-prescribed workflow. Verify product capabilities in your actual subscription before implementation.